Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1477930

Summary: OpenStack user repeatedly reports "Authorization failed for token ..." in neutron/server.log
Product: Red Hat OpenStack Reporter: Robin Cernin <rcernin>
Component: openstack-keystoneAssignee: John Dennis <jdennis>
Status: CLOSED NOTABUG QA Contact: nlevinki <nlevinki>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0 (Liberty)CC: hrybacki, jdennis, nkinder, panbalag, rcernin, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-10-20 14:37:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robin Cernin 2017-08-03 09:20:16 UTC 
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):

OSP8
Comment 3 John Dennis 2017-08-03 12:46:03 UTC 
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 14:00:40 UTC 
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?