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 ).
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 . 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  - https://review.openstack.org/#/c/76379/  -https://review.openstack.org/#/c/76411/  - https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L296
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev