[openstack-dev] [neutron] plumbing in request-id passing back to nova

Sean Dague sean at dague.net
Thu Jun 8 12:04:37 UTC 2017


We've now got Nova -> Glance, Neutron, Cinder. Cinder -> Nova, Glance is
up for review. I started looking at the Neutron code for this, and it's
wildly different, so need some help on what the right way forward is.

It appears that the novaclient construction happens only once per run
inside this Notifier construction -
https://github.com/openstack/neutron/blob/8d9fcb2d3037004cd1ad5136c449d80cdc5a5865/neutron/notifiers/nova.py#L47-L77
(where there is no context available).

Also, it appears that the way these API calls are emitted is through
implicit binds in the DBPlugin
(https://github.com/openstack/neutron/blob/8d9fcb2d3037004cd1ad5136c449d80cdc5a5865/neutron/db/db_base_plugin_v2.py#L152-L166)
so they are happening potentially well outside of any active context.

So... the questions, in order:

1) is construction path so disconnect from request processing that we've
got to give up on that pattern (my guess is yes).

2) when these events are emitted is there some way to have access to a
the context explicitly or do we have to do the magic reach back into the
tls for it?

3) is there any chance in the case of Nova -> Neutron -> Nova that we're
going to be able to keep track of the global_request_id coming from Nova
originally, so that the admin events coming back to Nova are tagged with
the original Nova initiating request?

Any advise here, or help in understanding is very welcomed. Thanks in
advance.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list