Open Stack

It seems like a change to using internal RPC interfaces would be pretty
unstable at this point.

Can we start by identifying the shortcomings of the HTTP interface and see
if we can address them before making the jump to using an interface which
has been internal to Neutron so far?

I scanned through the etherpad and I really like Salvatore's idea of adding
a service plugin to Neutron that is designed specifically for interacting
with Nova. All of the Nova notification interactions can be handled there
and we can add new API components designed for Nova's use (e.g. syncing
data, etc). Does anyone have any objections to that approach?

On Fri, Jan 23, 2015 at 7:04 AM, Gary Kotton <gkotton at vmware.com> wrote:

> Hi,
> As Salvatore mentioned this was one of the things that we discussed at the
> San Diego summit many years ago. I like the idea of using an RPC interface
> to speak with Neutron (we could do a similar thing with Cinder, glance
> etc). This would certainly address a number of issues with the interfaces
> that we use at the moment. It is certainly something worthwhile discussing
> next week.
> We would need to understand how to define versioned API¹s, how to deal
> with extensions etc.
> Thanks
> Gary
>
> On 1/23/15, 2:59 PM, "Russell Bryant" <rbryant at redhat.com> wrote:
>
> >On 01/22/2015 06:40 PM, Salvatore Orlando wrote:
> >>     I also like the idea of considering the RPC interface. What kind of
> >>     stability / versioning exists on the Neutron RPC interface?
> >>
> >>
> >> Even if Neutron does not have fancy things such as objects with
> >> remotable method, I think its RPC interfaces are versioned exactly in
> >> the same way as Nova. On REST vs AMQP I do not have a strong opinion.
> >> This topic comes up quite often; on the one hand REST provides a cleaner
> >> separation of concerns between the two projects; on the other hand RPC
> >> will enable us to design an optimised interface specific to Nova. While
> >> REST over HTTP is not as bandwidth-efficient as RPC over AMQP it however
> >> allow deployers to use off-the-shelf tools for HTTP optimisation, such
> >> as load balancing, or caching.
> >
> >Neutron uses rpc versioning, but there are some problems with it (that I
> >have been working to clean up).  The first one is that the interfaces
> >are quite tangled together.  There are interfaces that appear separate,
> >but are used with a bunch of mixin classes and actually presented as a
> >single API over rpc.  That means they have to be versioned together,
> >which is not really happening consistently in practice.  I'm aiming to
> >have all of this cleared up by the end of Kilo, though.
> >
> >The other issue is related to the "fancy things such as objects with
> >remotable methods".  :-)  The key with this is versioning the data sent
> >over these interfaces.  Even with rpc interface versioning clear and
> >consistently used, I still wouldn't consider these as stable interfaces
> >until the data is versioned, as well.
> >
> >--
> >Russell Bryant
> >
> >__________________________________________________________________________
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150123/b1993046/attachment.html>