Open Stack

On 22 January 2015 at 17:09, Sean Dague <sean at dague.net> wrote:

> On 01/22/2015 10:28 AM, Salvatore Orlando wrote:
> > Hi,
> >
> > We have attempted several times to start a conversation around the
> > interface between nova and neutron and its problems, starting with the
> > fact that it's chatter than two Italians arguing about football (*).
> > Indeed the first attempt at fixing these problems goes back to the Fall
> > 2012 summit [1]. While we probably don't want to introduce yet another
> > service to this aim, it might be worth giving another shot at having
> > these two project communicate in a decent way. I know that other
> > developers are interested in this and are probably even already actively
> > working on this topic.
> >
> > In my opinion it might not be such a bad idea to start this conversation
> > at the upcoming nova meetup, if there will be enough interest from the
> > participants. I have started the etherpad [2] for discussing issues of
> > the current implementation, goals, architecture, and design.
> >
> > As for timelines, it is very likely already too late for shipping this
> > in Kilo, but we're probably still on time for completing this work by
> > the "L" release.
> >
> > Salvatore
> >
> > (*) being Italian I am entitled to make jokes about Italians without
> > offending anyone, I hope.
> >
> > [1] https://etherpad.openstack.org/p/grizzly-newtonian
> > [2] https://etherpad.openstack.org/p/nova-neutron-interface-rework
>
> Interesting stuff. I conceptually like the idea of nova-compute doing
> the leg work for sub resources (like the network) as it feels like error
> handling is simpler given it's closeness to the actual VMs that are
> running.
>

That's true for the nova-network use case. In the neutron case instead
nova-compute ends up calling the neutron server which then operates on the
host through its agent. So we probably have different workflows, and the
one currently performed when using neutron is a bit "erratic" since it goes
from nova-api to nova-compute where the instance is built; then it calls
into neutron-server whose network configuration is picked up by the agent
which configures networking on the same host where nova-compute is running!


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



>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150123/533bf5ff/attachment.html>