Open Stack

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.

Cheers,
Armando

On Fri, May 10, 2013 at 2:44 PM, Dan Smith <dms at danplanet.com> wrote:

> > Clearly one reason the "proxy" systems are integrating with Nova is
> > a desire from OpenStack users to control those systems via the
> > OpenStack Compute API (and possibly the EC2-compat API as well, I
> > guess).  It sounds like the cells approach would enable that?
>
> Yes. The parent cell has the externally-facing nova-api node which is
> the "value" to these other systems. Requests are sent down to the child
> cell to handle somewhat autonomously.
>
> > But I think another key reason is to gain some of the flexibility
> > in scheduling and placement, including pluggable scheduling
> > algorithms and concepts like host-aggregates, availability zones,
> > etc.  I'm less clear on whether cells would enable that (seems like
> > some comments imply it would not?).
>
> If I understand your question correctly, it would, and that's precisely
> the point, I think. These other systems have different goals in their
> scheduling and placement, often making decisions to migrate workloads
> for load balancing or automatic fault avoidance. By letting them expose
> that at the compute level instead of the virt level, they can avoid the
> need to drive awareness of these operations (both configuration and
> potentially notification after a change) into nova-compute itself.
> Since we're trying to whittle nova-compute down to the smallest
> reasonable amount of function with as little state as possible, this
> helps avoid a conflict between the two goals.
>
> --Dan
>
> _______________________________________________
> 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/baad2c49/attachment.html>