Open Stack

Russell,

Agreed, even though nova-api has the API and extensions framework that is
technology agnostic, so it would be a shame see it go to waste in case a
proxy was going to be implemented separately.

Thanks,
Armando

On Fri, May 10, 2013 at 4:20 PM, Russell Bryant <rbryant at redhat.com> wrote:

> On 05/10/2013 10:55 AM, Armando Migliaccio wrote:
> > I also think that cells, as a concept for allowing more complex systems
> > like vCenter to tap into Nova, is worth exploring. We need a higher
> > enough level-of-abstraction to achieve such integration, and the virt
> > layer is clearly too deep down in the Nova stack.
> >
> > Chris Behrens mentioned XenServer/XCP pools...these are managed via host
> > aggregates: a concept that evolved in Nova over a few releases now, and
> > it might be worth exploring too.
> >
> > Moreover, if we look at other OpenStack projects, Quantum is a clear
> > example of a common API (and yet extensible) that abstracts many
> > heterogeneous back-end plugins: you have plugins that require certain
> > services to run, whereas others do not.
> >
> > Perhaps with little or even no work at all on nova-api, we can allow
> > other cloud/virt management systems to integrate with OpenStack directly
> > at the API layer. In the end, if these systems we're talking about
> > (vSphere, oVirt, HyperV, etc) conceptually work just like Nova
> > (providing their own scheduling, fail-over, etc), it might be as simple
> > as providing an adaption layer in front of their API's, thus eliminating
> > the need of implementing the full Nova stack (schedulers, conductors,
> > queues, etc.).
> >
> > I gather that this is what using cells would enable to a degree.
>
> Indeed, that's where this cells idea is headed.
>
> This cells approach has some really nice properties, though.  If it was
> just about supporting the API, I'd argue it shouldn't be in Nova at all.
>  It's overly complex to just be an API proxy.
>

> Exposing these systems at the cells layer lets you support multiple
> systems in the same infrastructure in a fairly clean way.  Suppose
> you're standing up a new OpenStack deployment using KVM.  All of your
> new libvirt+KVM nodes could live in one compute cell.  Let's also say
> you have some legacy existing virt management infrastructure that you'd
> like to take advantage of as capacity for your OpenStack cloud (oVirt or
> whatever).  That could be exposed as another compute cell.  Cell
> scheduling allows you to implement policy about which instances should
> go to which cell of compute resources.
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130510/72019c8d/attachment.html>