Zheng 先生- I *think* you're right that 'network' should be included in [2]. I can't think of any reason it shouldn't be. Does that fix the problem by itself? I believe the Neutron API code is already getting its auth from context... sometimes [5]. If you want to make sure it's an admin token, add admin=True here [6] - but that may have further-reaching implications. [5] https://github.com/openstack/nova/blob/9519601401ee116a9197fe3b5d571495a96912e9/nova/network/neutronv2/api.py#L155 [6] https://github.com/openstack/nova/blob/9519601401ee116a9197fe3b5d571495a96912e9/nova/network/neutronv2/api.py#L1190 Good luck. efried On 02/06/2018 04:48 AM, Zhenyu Zheng wrote: > Hi Nova, > > While doing some test with my newly deployed devstack env today, it > turns out that the default devstack deployment cannot cleanup networks > after the retry attempt exceeded. This is because in the deployment with > super-conductor and cell-conductor, the retry and cleanup logic is in > cell-conductor [1], and by default the devstack didn't put Neutron > endpoint info in nova_cell1.conf. And as the neutron endpoint is also > not included in the context [2], so we can't find Neutron endpoint when > try to cleanup network [3]. > > The solution is simple though, ether add Neutron endpoint info in > nova_cell1.conf in devstack or change Nova code to support get auth from > context. I think the latter one is better as in real deployment there > could be many cells and by doing this can ignore config it all the time. > > Any particular consideration that Neutron is not included in [2]? > > Suggestions on how this should be fixed? > > I also registered a devstack bug to fix it in devstack [4]. > > [1] https://github.com/openstack/nova/blob/bccf26c93a973d000e4339843ce9256814286d10/nova/conductor/manager.py#L604 > [2] https://github.com/openstack/nova/blob/9519601401ee116a9197fe3b5d571495a96912e9/nova/context.py#L121 > [3] https://bugs.launchpad.net/nova/+bug/1747600 > [4] https://bugs.launchpad.net/devstack/+bug/1747598 > > BR, > > Kevin Zheng > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >