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.<div>


<br></div><div>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.<br><div>
<br></div><div>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.</div>


<div><br></div><div>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.).</div>


<div><br></div><div>I gather that this is what using cells would enable to a degree.</div><div><br></div><div>Cheers,</div><div>Armando</div><div><br><div class="gmail_quote">On Fri, May 10, 2013 at 2:44 PM, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> Clearly one reason the "proxy" systems are integrating with Nova is<br>
> a desire from OpenStack users to control those systems via the<br>
> OpenStack Compute API (and possibly the EC2-compat API as well, I<br>
> guess).  It sounds like the cells approach would enable that?<br>
<br>
</div>Yes. The parent cell has the externally-facing nova-api node which is<br>
the "value" to these other systems. Requests are sent down to the child<br>
cell to handle somewhat autonomously.<br>
<div><br>
> But I think another key reason is to gain some of the flexibility<br>
> in scheduling and placement, including pluggable scheduling<br>
> algorithms and concepts like host-aggregates, availability zones,<br>
> etc.  I'm less clear on whether cells would enable that (seems like<br>
> some comments imply it would not?).<br>
<br>
</div>If I understand your question correctly, it would, and that's precisely<br>
the point, I think. These other systems have different goals in their<br>
scheduling and placement, often making decisions to migrate workloads<br>
for load balancing or automatic fault avoidance. By letting them expose<br>
that at the compute level instead of the virt level, they can avoid the<br>
need to drive awareness of these operations (both configuration and<br>
potentially notification after a change) into nova-compute itself.<br>
Since we're trying to whittle nova-compute down to the smallest<br>
reasonable amount of function with as little state as possible, this<br>
helps avoid a conflict between the two goals.<br>
<span><font color="#888888"><br>
--Dan<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div>