I checked the env provided by Leontiy and see the following:
When talking to neutron-server on behalf of a user (thus, using a user token), nova-api sometimes receives 401 caused by neutron-server not being able to validate a passed token (due to various reasons: sometimes token is not found and keystone returns 404, sometimes keystone fails with 503 - http://paste.openstack.org/show/231809/).
401 is usually handled by python-*client's by getting a new token from Keystone, but in order to do that, one would need to pass user credentials. And when operations are performed on behalf of a user (like when you do something like `nova show server_name` and nova-api goes to neutron-server to get networking information), it's just not possible as nova/etc just don't have user credentials.
In case of nova/python-neutronclient a very misleading exception is raised - http://paste.openstack.org/show/212665/ . It effectively means - "the token you passed is invalid (read: can not be found in Keystone), please get a new one and retry the request". Obviously, we can't get a new token without user credentials, so Nova must return 401 to the user, so that he/she could do that. Instead it fails with 500 producing an obscure log error message.
This is a *valid* Nova issue in the sense, that nova-api should return a proper HTTP response code. Still, this would not prevent requests from failing, unless users will manually retry the original request passing a new token.
That being said, I'm not sure, that 401 vs 500 response code returned by nova-api should be treated as High and fixed in 6.1 (this is already fixed in Kilo).
I checked the env provided by Leontiy and see the following:
When talking to neutron-server on behalf of a user (thus, using a user token), nova-api sometimes receives 401 caused by neutron-server not being able to validate a passed token (due to various reasons: sometimes token is not found and keystone returns 404, sometimes keystone fails with 503 - http:// paste.openstack .org/show/ 231809/).
401 is usually handled by python-*client's by getting a new token from Keystone, but in order to do that, one would need to pass user credentials. And when operations are performed on behalf of a user (like when you do something like `nova show server_name` and nova-api goes to neutron-server to get networking information), it's just not possible as nova/etc just don't have user credentials.
In case of nova/python- neutronclient a very misleading exception is raised - http:// paste.openstack .org/show/ 212665/ . It effectively means - "the token you passed is invalid (read: can not be found in Keystone), please get a new one and retry the request". Obviously, we can't get a new token without user credentials, so Nova must return 401 to the user, so that he/she could do that. Instead it fails with 500 producing an obscure log error message.
This is a *valid* Nova issue in the sense, that nova-api should return a proper HTTP response code. Still, this would not prevent requests from failing, unless users will manually retry the original request passing a new token.
That being said, I'm not sure, that 401 vs 500 response code returned by nova-api should be treated as High and fixed in 6.1 (this is already fixed in Kilo).