Open Stack

Um...I wonder if  we are saying the same thing: I am thinking that for
implementing a nova-api proxy one would need to provide their
compute_api_class, that defaults to nova.compute.api.API. Incidentally,
when using cells this becomes nova.compute.cells_api.ComputeCellsAPI (for
the top-level). By implementing the compute API class surely you don't need
necessarily to hook into how Nova works, no?

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

> On 05/10/2013 11:37 AM, Armando Migliaccio wrote:
> > 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.
>
> I'm not sure that's true.  There's general WSGI infrastructure (plenty
> of options there outside of nova's infrastructure) and then there's the
> implementation of the API, which is all tied into the way nova works.
> It requires the nova database with its view of the state of the world.
> If all you want is an API proxy, why would you want to have to go
> through all of this pain to keep nova's view in sync with some other
> virt management system's view?  *That* seems like a waste to me.
>
> --
> 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/f49102c3/attachment.html>