← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1742546] Re: Keystone appears to initiate each new request using the previous' request-id

 

[Expired for OpenStack Identity (keystone) because there has been no
activity for 60 days.]

** Changed in: keystone
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1742546

Title:
  Keystone appears to initiate each new request using the previous'
  request-id

Status in OpenStack Identity (keystone):
  Expired

Bug description:
  Environment
  ~~~~~~~~~~~
  * openstack-ansible version: 16.0.2
  * Target OS: Ubuntu 16.04 Xenial
  * Keystone deployed in containers, running on uWSGI (per OSA defaults)
  * Keystone baseline (as provided by OSA): 6a67918f9d5f39564af8eacc57b80cba98242683 # HEAD of "stable/pike" as of 28.09.2017

  Symptom
  ~~~~~~~
  When running Keystone with debug=True, one can observe in keystone.log that each incoming request appears to "borrow" the req Id from the previous one served by that particular uWSGI process.

  Analysis
  ~~~~~~~~
  This may be just cosmetic but one wonders if this is the indication of smth executing under the wrong context (and hence could have security implications?)

  Evidence
  ~~~~~~~~
  In this slightly edited log excerpt from a specific worker (11207): http://paste.openstack.org/show/642496/ one can for instance see that the request incoming at 20:30:38.035 borrows "req-e4456225-01a5-498e-9b73-ad9772a54781" from the previous request that completed execution at 20:30:25.962.  The top of the log shows the same pattern and it's consistent throughout

  Notes: 
  1. there's a ~5s delay before 20:30:25.957 which is a different issue (actually the one I was investigating which lead me to notice the pattern reported here
  2. The log has been slightly edited: I removed the "UUID1 UUID2 default - default" suffix after the req Id for legibility (both UUIDs were constants); this is what allowed me to spot the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1742546/+subscriptions


References