Bug 1477930 - OpenStack user repeatedly reports "Authorization failed for token ..." in neutron/server.log
OpenStack user repeatedly reports "Authorization failed for token ..." in neu...
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: John Dennis
Depends On:
  Show dependency treegraph
Reported: 2017-08-03 05:20 EDT by Robin Cernin
Modified: 2017-11-13 09:22 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-10-20 10:37:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robin Cernin 2017-08-03 05:20:16 EDT
Description of problem:

We can see one service (neutron) spamming the server.log logs with "Authorization failed for token" for specific user and it is repeating every hour in random pattern.

Since the user never Authenticate successfully we will never see the request the user is sending.

Is there a way for us to either:

*) Disable this logging for the "Authorization failed for token" for this specific user (nobody is complaining)

*) Find out the problem why the token is deleted in DB at the time the user requested it?

*) Is this expected behavior?

Version-Release number of selected component (if applicable):

Comment 3 John Dennis 2017-08-03 08:46:03 EDT
Losing the connection to the MySQL server during the query would seem to be the root cause of the problem. Have you investigated what's going wrong with your DB?
Comment 4 Robin Cernin 2017-08-03 10:00:40 EDT
Let me update the Bugzilla as well, the last comment is valid. There was an issue in MySQL database, however this happens also when there is no database issue and only for this specific user.

We have checked whether the token cleanup job might be the cause - what we thought is that if there is an cleanup token job while the token is requested and expired it would not be found. However the cleanup job works fine in the environment and there are 0 expired tokens in the DB.

The other examples are same as this one, it shows Authorization failed for token, and when we try to connect to mysql and look for the token we can't find it either.

Question is why does it try to use the old token which is already purged?

Note You need to log in before you can comment on or make changes to this bug.