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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
