FWIW: Current OpenStack status

Mo Morsi mmorsi at redhat.com
Thu May 3 10:49:11 UTC 2012


On 04/26/2012 03:27 PM, Ian McLeod wrote:
>>> Going forward we are working to make the image management bits conductor
>>> pluggable so we can swap things in and out. AFAIK it looks like
>>> boxgrinder supports building images for openstack so we should be able
>>> to use that for that scenario until imagefactory supports openstack (at
>>> which point we can just enable the flag to swap that back in)
>>>
>>>  -Mo
>> This point I have to disagree with.  While we _are_ in the process of
>> making our factory interaction into a rails engine, that does not
>> imply any plans to switch _away_ from factory, even temporarily.  In
>> factory v2, it will actually also serve some of the functionality that iwhd
>> currently provides us, so swapping it out entirely would be
>> detrimental to the whole stack.  In fact, factory _mostly_ has
>> openstack support already, from what I understand.  Iirc, there has
>> been a working rackspace impl for quite some time, even though we have
>> not consumed it from conductor.  

What is the feasibility of using multiple image management backends in
conductor at the same time? Or at least allowing the admin to select
which ones are deployed?

It might make sense to make use of these on a per-provider-type basis,
as I can foresee a situation in which certain image generation utilities
have limited or no support for particular cloud providers (for example
those that provide proprietary/restricted interfaces). It would be nice
to allow the conductor end-user to use those on an on-demand basis,
making use of the native image generation / management tooling or other
in those situations.



> We do indeed have some rarely-used and sparsely tested support for
> snapshot style RackSpace builds.
>
> However, what I gather will be more interesting to people is the ability
> to upload scratch-built images via Glance.  I'm working on support for
> that now and it should be completed in our current sprint, which ends in
> 2.5 weeks.  (It may be available in git much sooner than that.)

Cool, would a release of imagefactory in Fedora be able to be cut after
that? Would be the easiest way for us to leverage those new capabilities
from Conductor.


> A larger question is what specific OpenStack configurations we wish to
> support.  It appears that OpenStack can use just about every commonly
> deployed hypervisor:
>
> http://docs.openstack.org/cactus/openstack-compute/admin/content/selecting-a-hypervisor.html
>
> I'm pretty sure we won't be able to produce a single binary image that
> can run on all of those.  For example, we know that a RHEL5 image must
> be configured to boot a different kernel in the Xen environment.  It's
> also unclear to what extent OpenStack is able to munge the image format
> in a multiple hypervisor configuration.  Can it, for example, take a
> qcow2 image and transform it to VMDK in order to launch an ESX VM? 
>

If we added support to run the latest Fedora / RHEL on KVM (for example)
would we be able to make use of the native tooling to build images for
other non-supported scenarios (in the manner described above). This way
we'd be able to leverage imagefactory for the scenarios it'd make sense
to support while allowing the end user to use alternative solutions on a
'you're-on-your-own' basis.

  -Mo




More information about the aeolus-devel mailing list