Bug 1477930 - OpenStack user repeatedly reports "Authorization failed for token ..." in neutron/server.log
Summary: OpenStack user repeatedly reports "Authorization failed for token ..." in neu...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: John Dennis
QA Contact: nlevinki
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-03 09:20 UTC by Robin Cernin
Modified: 2020-12-14 09:20 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-20 14:37:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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?


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