Open Stack

Hi,

Dan Smith and I have been working on the integration between nova and
neutron to have neutron issue callbacks into nova to trigger certain
events. One of the things I'm trying to figure out is how to support
multiple nova regions with this kind of interaction since neutron would now
needs to know which nova-api endpoint to send an event to. My current train
of thought is that if you're running with multiple regions that we should
require each nova-compute host to set os_region_name in it's nova.conf
(this seems to already be a requirement for cinder with multiple regions).
Then, we'll pass os_region_name in the port so that neutron can be aware of
the region each port lives  (accomplished here [1][2]).

The second part of the problem where the difficulty seems to be is when
neutron needs to notify nova as we'll need to determine the nova endpoint
that we should send to. It looks like one way we can go about this is by
caching the latest X_SERVICE_CATALOG value from the request to neutron
(which contains the list of keystone endpoints). This seems to be provided
by default, though there is a configuration option here to disable it [3].
I just want to make sure if we go this route that is the right decision.

The other options could be to statically configure the endpoints in neutron
which might not be ideal as if they change you'd have to update that value
in multiple places (this would definitely make things simpler though :) and
would be reliable as well. ). Alternatively, have neutron query keystone
for the endpoints periodically with some caching in combination with
using X_SERVICE_CATALOG. This would be helpful in the case were neutron
doesn't see any new requests and has an out dated catalog list until it
sees another request (which could be possible if there isn't much turn in
the system).

I was curious if anyone had any other ideas/thoughts on how to tackle this
or which approach makes the most sense.

Best,

Aaron

[1] - https://review.openstack.org/#/c/76379/

[2] -https://review.openstack.org/#/c/76411/

[3] -
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L296
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/eee30ccf/attachment.html>