<div dir="ltr">
        
        
        


<p style="margin-bottom:0in">
<font color="#222222"><font size="3" face="arial, helvetica, sans-serif">Hi,</font></font></p>
<p style="margin-bottom:0in">
<font color="#222222"><font size="3" face="arial, helvetica, sans-serif">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]).</font></font></p>
<p style="margin-bottom:0in">
<font color="#222222"><font size="3" face="arial, helvetica, sans-serif">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.</font></font></p>
<p style="margin-bottom:0in"><font face="arial, helvetica, sans-serif"><font size="3">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).</font></font></p>
<p style="margin-bottom:0in">
<font color="#222222"><font size="3" face="arial, helvetica, sans-serif">I was curious
if anyone had any other ideas/thoughts on how to tackle this or which approach makes the most sense. </font></font></p>
<p style="margin-bottom:0in">
<font color="#222222"><font size="3" face="arial, helvetica, sans-serif">Best,</font></font></p><p style="margin-bottom:0in"><span style="font-family:arial,helvetica,sans-serif;font-size:medium">Aaron</span></p><p style="margin-bottom:0in">
<font face="arial, helvetica, sans-serif"><span style="font-size:medium">[1] - </span><font size="3"><a href="https://review.openstack.org/#/c/76379/">https://review.openstack.org/#/c/76379/</a></font></font></p><p style="margin-bottom:0in">
<font face="arial, helvetica, sans-serif"><span style="font-size:medium">[2] -</span><font size="3"><a href="https://review.openstack.org/#/c/76411/">https://review.openstack.org/#/c/76411/</a></font></font></p><p style="margin-bottom:0in">
<span style="font-family:arial,helvetica,sans-serif;font-size:medium">[3] - <a href="https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L296">https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L296</a></span></p>
</div>