Open Stack

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

We have lots of admin-only APIs.

> Does it make sense that the user would now be able to send messages
> to this API?

Potentially. Right now you can ask for a refresh of their network info
if things are stale, and some RAX people mentioned that they would like
to be able to trigger network resets and some other sorts of things
through that mechanism.

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

Because we change our RPC APIs all the time. If an external component
has to consume our RPC messages reliably, that means either we have to
make sure that component tracks the changes, or we avoid making them. On
the other hand, our REST APIs are specifically designed and carefully
monitored to maintain compatibility with external things.

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

It's optional, and for better integration with Neutron and Nova. I don't
really think that it's as nova-specific as you're implying. IIRC, the
neutron side just fires a notification any time a port changes state
right now.

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

Neutron consuming Nova's RPC or Nova consuming Neutron's RPC.. either
way, it's not how I'd choose to go about it.

> It could similarly be a queue with some defined message format.

I think that's what we've implemented, no? It's a well-defined format
that describes an event. It has nothing nova-specific in it.

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

Sure, if you want to go extend this mechanism to remove the static
configuration and allow for dynamic registration of who receives these
messages, I would expect that would be fine. We'd need to figure out how
a single Nova deployment will manage registering with Neutron in an
efficient way, but I'm sure that could be done.

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

Well, I'm not sure why Cinder would need to receive notifications from
Neutron, but I understand what you mean. Like I said, nothing about how
it's currently architected prevents this from happening, AFAIK, other
than the fact that it's currently managed by static configuration. If
you want to add a subscription interface to register for these so that
neutron can supply notifications to multiple entities dynamically, then
that seems like a natural next step. I'm sure Cinder would prefer that
as well.

--Dan