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

<div><br></div><div>Thanks,</div><div>Armando</div><div><br><div class="gmail_quote">On Fri, May 10, 2013 at 4:20 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/10/2013 10:55 AM, Armando Migliaccio wrote:<br>
> I also think that cells, as a concept for allowing more complex systems<br>
> like vCenter to tap into Nova, is worth exploring. We need a higher<br>
> enough level-of-abstraction to achieve such integration, and the virt<br>
> layer is clearly too deep down in the Nova stack.<br>
><br>
> Chris Behrens mentioned XenServer/XCP pools...these are managed via host<br>
> aggregates: a concept that evolved in Nova over a few releases now, and<br>
> it might be worth exploring too.<br>
><br>
> Moreover, if we look at other OpenStack projects, Quantum is a clear<br>
> example of a common API (and yet extensible) that abstracts many<br>
> heterogeneous back-end plugins: you have plugins that require certain<br>
> services to run, whereas others do not.<br>
><br>
> Perhaps with little or even no work at all on nova-api, we can allow<br>
> other cloud/virt management systems to integrate with OpenStack directly<br>
> at the API layer. In the end, if these systems we're talking about<br>
> (vSphere, oVirt, HyperV, etc) conceptually work just like Nova<br>
> (providing their own scheduling, fail-over, etc), it might be as simple<br>
> as providing an adaption layer in front of their API's, thus eliminating<br>
> the need of implementing the full Nova stack (schedulers, conductors,<br>
> queues, etc.).<br>
><br>
> I gather that this is what using cells would enable to a degree.<br>
<br>
</div>Indeed, that's where this cells idea is headed.<br>
<br>
This cells approach has some really nice properties, though.  If it was<br>
just about supporting the API, I'd argue it shouldn't be in Nova at all.<br>
 It's overly complex to just be an API proxy.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Exposing these systems at the cells layer lets you support multiple<br>
systems in the same infrastructure in a fairly clean way.  Suppose<br>
you're standing up a new OpenStack deployment using KVM.  All of your<br>
new libvirt+KVM nodes could live in one compute cell.  Let's also say<br>
you have some legacy existing virt management infrastructure that you'd<br>
like to take advantage of as capacity for your OpenStack cloud (oVirt or<br>
whatever).  That could be exposed as another compute cell.  Cell<br>
scheduling allows you to implement policy about which instances should<br>
go to which cell of compute resources.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>