Open Stack

Hi,

Sorry for late reply, please see replies inline.

I have additional concern that API is something that's user facing so
basically now Nova is exposing some internal synchronization detail to
the outside world.
Does it make sense that the user would now be able to send messages to
this API?

----- Original Message -----
> > Aside from creating a sort of cyclic dependency between the two, it
> > is my understanding that Neutron is meant to be a "stand alone"
> > service capable of being consumed by other compute managers (i.e.
> > oVirt). This breaks that paradigm.
> 
> <snip>
> 
> > So my question is: Why use API and not RPC?
> > 
> > I saw that there is already a notification system in Neutron that
> > notifies on each port update (among other things) which are
> > currently consumed by Ceilometer. Why not have Nova use those
> > notifications to decide that a VIF got plugged correctly, floating
> > IPs changed, and so on?
> 
> To your point above, having either service sit on the other's RPC bus
> ties them together far closer than having them consume each other's REST
> API, IMHO. Further, Nova's internal RPC mechanics are controlled pretty
> tightly for upgrade compatibility and I don't think I'd want another
> service sitting on that bus that we have to worry about when we're
> coordinating a change across releases (which we do quite often). We
> consume Neutron's services via the REST API because that's what is
> exposed externally and guaranteed to be stable -- the same goes for
> Neutron consuming anything from Nova.

Not sure why RPC is more coupled than API. Maybe you could explain?

Currently it's a very specific API putting a burden on Neutron to now know
what is VIF and what state is necessary for this VIF to be working,
instead of having these calculations in Nova (which is of course aware of
VIF, and of Port).

I wasn't suggesting touching Nova's RPC but rather utilize the existing
notifications sent from Neutron to achieve the same logic. So not sure what
changes you believe are to be coordinated from Nova's POV.

Also, RPC is just what is used today. It could similarly be a queue with
some defined message format. IMHO "RPC" is just that, it's not really
making any remote procedure calls in the notifications it sends.

We could alternatively provide a "callback" functionality that allows
various clients to receive notifications from Neutron, specifying an
address to send these details to.

> 
> > I believe the rationale here was that nova's API interface is only
> > currently exposed via a rest API over http so leveraging this
> > existing framework seemed like a good place to do it. In addition,
> > there didn't seem to be an obvious advantage to using RPC rather
> > than the rest interface. Lastly, this new interface that nova exposes
> > is generic and not neutron specific as it can be used for other type
> > of notifications that things want to send nova. I added Dan Smith to
> > CC to keep me honest here as I believe this was the rationale.
> 
> Yeah, we've already got plans in place to get Cinder to use the
> interface to provide us more detailed information and eliminate some
> polling. We also have a very purpose-built notification scheme between
> nova and cinder that facilitates a callback for a very specific
> scenario. I'd like to get that converted to use this mechanism as well,
> so that it becomes "the way you tell nova that things it's waiting for
> have happened."

Not sure how you consider this "mechanism" something generic since it's
facilitating only Nova while there might be a number of different services
interested in this information.
Now Neutron needs to be aware of VIF and Nova's expectations of Neutron
in regards to that VIF, which is highly tightly coupled.

Using a notification scheme where any subscriber can receive the event
from Neutron/Cinder/etc and handle it how it needs instead would be
much more decoupled, IMHO.

> 
> --Dan
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>