[Beaker-devel] OpenStack based dynamic virtualization

Nick Coghlan ncoghlan at redhat.com
Thu Dec 19 02:05:21 UTC 2013


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.

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)


More information about the Beaker-devel mailing list