On 12/19/2013 03:27 AM, Lucas Meneghel Rodrigues wrote:
On 12/18/2013 06:23 AM, Nick Coghlan wrote:
We've been talking about possibly changing the existing dynamic virtualization to work with OpenStack instead of oVirt for a while, and I've now hammered that into a hopefully coherent concrete proposal:
http://beaker-project.org/dev/proposals/dynamic-virtualization.html
I did read the proposal, it is good and clear.
Thanks!
The key points in there are too:
- associate lab controllers with OpenStack regions
- map host filtering to flavour filtering
- generate bootstrap images in Glance as part of distro import
- use the bootstrap images for dynamic provisioning (rather than
configuring netboot and then rebooting the system)
- ensure console logging is hooked up properly
Provisioning based on specific images is explicitly deferred, since we'd have to map a bunch of the stuff we do in the kickstart post to cloud-init, and I'd prefer to put that off to a later iteration. By
Is mapping the post install stage to cloud-init significantly harder than providing the boostrap images that launch anaconda?
Yes, for a few different reasons. Firstly, we use some anaconda features to configure yum repos and install packages on the target system, and would have to come up with new ways of doing those in a cloud-init based solution.
Secondly, by building on https://github.com/redhat-openstack/image-building-poc (which is what I'm suggesting we do in order to create these initial bootstrapping images), we can eventually start creating the appropriate full system images in Glance when a distro is imported, rather than relying on them being created externally and just providing a way to pass the image name into Beaker. (While requesting specific images is something we think we should support, that's separate from transparently using OpenStack whenever feasible).
Finally, we currently support a variety of kickstart specific customisation options through ks_meta, ks_appends and custom kickstart templates. By bootstrapping Anaconda rather than a full system image, those will just work, whereas if we try to jump straight to image based provisioning, there will be quite a few existing recipes that will still need to use bare metal systems because they need the customisation options.
By doing the bootstrapping option first, when we later add support for image based provisioning, we simply won't support those kickstart specific customisation options, but will instead add new ones that are compatible with both kickstart and cloud-init.
I'll add some more of this rationale to the proposal today, since it's a good question.
Cheers, Nick.