[Yahoo-eng-team] [Bug 1620764] [NEW] migration test fails on table addition
Public bug reported: If expand repo migration adds a table, corresponding unit test fails attempting to access created table with the error "Table does not exist" [0] [0] http://logs.openstack.org/88/208488/51/check/gate-keystone-python27 -db-ubuntu-xenial/81311f3/console.html#_2016-09-06_14_27_49_936937 ** Affects: keystone Importance: Undecided Status: New -- 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/1620764 Title: migration test fails on table addition Status in OpenStack Identity (keystone): New Bug description: If expand repo migration adds a table, corresponding unit test fails attempting to access created table with the error "Table does not exist" [0] [0] http://logs.openstack.org/88/208488/51/check/gate-keystone- python27-db-ubuntu- xenial/81311f3/console.html#_2016-09-06_14_27_49_936937 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1620764/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1569389] [NEW] set_config_defaults() never called on testing
Public bug reported: I can even put a line None[0] in the keystone.common.config.set_config_defaults() and tests run as nothing wrong happened. Consequently, any defaults override put there has no effect during testing. ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: In Progress -- 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/1569389 Title: set_config_defaults() never called on testing Status in OpenStack Identity (keystone): In Progress Bug description: I can even put a line None[0] in the keystone.common.config.set_config_defaults() and tests run as nothing wrong happened. Consequently, any defaults override put there has no effect during testing. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1569389/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1501698] [NEW] LDAP identity backend does not honor list_limit
Public bug reported: list_limit set in [identity] section is not used to limit user list: the result contains entire set of users returned by the query ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: New ** Changed in: keystone Assignee: (unassigned) => Alexander Makarov (amakarov) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1501698 Title: LDAP identity backend does not honor list_limit Status in Keystone: New Bug description: list_limit set in [identity] section is not used to limit user list: the result contains entire set of users returned by the query To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1501698/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1496512] Re: Misplaced memcache servers in keystone config cause token loss
master: https://review.fuel-infra.org/#/c/11662/ 7.0: https://review.fuel-infra.org/#/c/8189 ** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Assignee: (unassigned) => Alexander Makarov (amakarov) ** No longer affects: keystone ** Also affects: mos/7.0.x Importance: Undecided Status: New ** Changed in: mos/7.0.x Status: New => Fix Committed ** Changed in: mos/7.0.x Assignee: (unassigned) => Alexander Makarov (amakarov) ** Changed in: mos/7.0.x Milestone: None => 7.0 ** Changed in: mos/7.0.x Importance: Undecided => Critical ** Changed in: mos Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1496512 Title: Misplaced memcache servers in keystone config cause token loss Status in Mirantis OpenStack: In Progress Status in Mirantis OpenStack 7.0.x series: Fix Committed Bug description: If memcache servers specified in [cache] section of keystone config are enumerated in different order on cloud controllers, tokens fail to validate as keystone searches the wrong memcache server if token issue and validation occur on different controllers. To manage notifications about this bug go to: https://bugs.launchpad.net/mos/+bug/1496512/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1494398] [NEW] AuthN fails if the tenant is recreated in the process
Public bug reported: Scenario: 2 requests are executed in parallel: 1) authentication against "the tenant" by tenant name 2) delete "the tenant" + create "the tenant" According to API contract authentication should pass, but internally all magic is done using tenant_id acquired at the very beginning of the request (1). So while formally tenant named "the tenant" exists, authentication fails as it's no mode accessible by it's old id. ** Affects: keystone Importance: Undecided Status: New ** Summary changed: - AuthN fails if the projects is recreated in the process + AuthN fails if the tenant is recreated in the process -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1494398 Title: AuthN fails if the tenant is recreated in the process Status in Keystone: New Bug description: Scenario: 2 requests are executed in parallel: 1) authentication against "the tenant" by tenant name 2) delete "the tenant" + create "the tenant" According to API contract authentication should pass, but internally all magic is done using tenant_id acquired at the very beginning of the request (1). So while formally tenant named "the tenant" exists, authentication fails as it's no mode accessible by it's old id. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1494398/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1493126] [NEW] openstack group create fails while using admin token
Public bug reported:
While using --os-token=ADMIN_TOKEN rather then admin user credentials
fails with error message:
$ openstack --os-token= group create "qwerty"
ERROR: openstack The request you have made requires authentication. (Disable
debug mode to suppress these details.) (HTTP 401) (Request-ID: req-8b45e<...>)
OS_USERNAME and OS_PASSWORD are set to ""
Keystone log contains:
2015-09-07 19:30:50.514850 14499 DEBUG keystone.middleware.core [-] RBAC:
auth_context: {} process_request
/opt/stack/keystone/keystone/middleware/core.py:209
2015-09-07 19:30:50.533697 14499 INFO keystone.common.wsgi [-] POST
http://172.16.51.28:5000/v3/groups
2015-09-07 19:30:50.536504 14499 WARNING keystone.common.controller [-] RBAC:
Bypassing authorization
2015-09-07 19:30:50.539266 14499 WARNING keystone.common.utils [-] Couldn't
find the auth context.
2015-09-07 19:30:50.547398 14499 WARNING keystone.common.wsgi [-] Authorization
failed. The request you have made requires authentication. (Disable debug mode
to suppress these details.) (Disable debug mode to suppress these details.)
from
Using admin credentials works fine.
---
Investigation gave me that the root cause of this is that during group creation
[0] the token information is being extracted from context [1] which is {empty}
for request authenticated using ADMIN_TOKEN [2]
[0]
https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L300
[1]
https://github.com/openstack/keystone/blob/master/keystone/common/utils.py#L523-L525
[2]
https://github.com/openstack/keystone/blob/master/keystone/middleware/core.py#L72
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1493126
Title:
openstack group create fails while using admin token
Status in Keystone:
New
Bug description:
While using --os-token=ADMIN_TOKEN rather then admin user credentials
fails with error message:
$ openstack --os-token= group create "qwerty"
ERROR: openstack The request you have made requires authentication. (Disable
debug mode to suppress these details.) (HTTP 401) (Request-ID: req-8b45e<...>)
OS_USERNAME and OS_PASSWORD are set to ""
Keystone log contains:
2015-09-07 19:30:50.514850 14499 DEBUG keystone.middleware.core [-] RBAC:
auth_context: {} process_request
/opt/stack/keystone/keystone/middleware/core.py:209
2015-09-07 19:30:50.533697 14499 INFO keystone.common.wsgi [-] POST
http://172.16.51.28:5000/v3/groups
2015-09-07 19:30:50.536504 14499 WARNING keystone.common.controller [-] RBAC:
Bypassing authorization
2015-09-07 19:30:50.539266 14499 WARNING keystone.common.utils [-] Couldn't
find the auth context.
2015-09-07 19:30:50.547398 14499 WARNING keystone.common.wsgi [-]
Authorization failed. The request you have made requires authentication.
(Disable debug mode to suppress these details.) (Disable debug mode to suppress
these details.) from
Using admin credentials works fine.
---
Investigation gave me that the root cause of this is that during group
creation [0] the token information is being extracted from context [1] which is
{empty} for request authenticated using ADMIN_TOKEN [2]
[0]
https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L300
[1]
https://github.com/openstack/keystone/blob/master/keystone/common/utils.py#L523-L525
[2]
https://github.com/openstack/keystone/blob/master/keystone/middleware/core.py#L72
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1493126/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1482271] [NEW] Race condition in multithreaded Apache/WSGI setup
Public bug reported: When configured as an Apache WSGI module a race condition is possible during keystone cache initialization: https://github.com/openstack/keystone/blob/master/keystone/common/kvs/core.py#L240 The operation raises exception region.RegionAlreadyConfigured. This is a result of the race condition involving global 'application' variable being initialized several times (1 per thread). application is required to be global according to Paste Deploy documentation: http://pythonpaste.org/deploy/ Apache modwsgi documentation suggests protecting global objects with thread locks: http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading#Building_A_Portable_Application ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1482271 Title: Race condition in multithreaded Apache/WSGI setup Status in Keystone: In Progress Bug description: When configured as an Apache WSGI module a race condition is possible during keystone cache initialization: https://github.com/openstack/keystone/blob/master/keystone/common/kvs/core.py#L240 The operation raises exception region.RegionAlreadyConfigured. This is a result of the race condition involving global 'application' variable being initialized several times (1 per thread). application is required to be global according to Paste Deploy documentation: http://pythonpaste.org/deploy/ Apache modwsgi documentation suggests protecting global objects with thread locks: http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading#Building_A_Portable_Application To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1482271/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1472306] [NEW] Broken ascii diagram in materialized path spec
Public bug reported: In the problem description of the spec: https://github.com/openstack/keystone-specs/blob/master/specs/liberty/materialize-project-hierarchy.rst A tree diagram is represented in variable width font because of the mistake in syntax: a string ending with '::' must precede the pseudo-graphics block for it to be displayed in a monospace font. ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Alexander Makarov (amakarov) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1472306 Title: Broken ascii diagram in materialized path spec Status in OpenStack Identity (Keystone): In Progress Bug description: In the problem description of the spec: https://github.com/openstack/keystone-specs/blob/master/specs/liberty/materialize-project-hierarchy.rst A tree diagram is represented in variable width font because of the mistake in syntax: a string ending with '::' must precede the pseudo-graphics block for it to be displayed in a monospace font. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1472306/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1420788] [NEW] Logging blocks on race condition under eventlet
Public bug reported: Wrong initialization order makes logging block on race condition under eventlet. bin/keystone-all launcher initialize logging first and after that does eventlet patching leaving logging system with generic thred.lock in critical sections what leads to infinite thread locks under high load. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1420788 Title: Logging blocks on race condition under eventlet Status in OpenStack Identity (Keystone): New Bug description: Wrong initialization order makes logging block on race condition under eventlet. bin/keystone-all launcher initialize logging first and after that does eventlet patching leaving logging system with generic thred.lock in critical sections what leads to infinite thread locks under high load. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1420788/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1417737] [NEW] KVS cache backend incompatible with redis-py
Public bug reported: Created Redis cache backend: https://review.openstack.org/#/c/150844/ Tempest revealed problem with locking: <11>Feb 3 14:56:14 node-27 keystone-all 'LuaLock' object has no attribute 'lock_timeout' 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi Traceback (most recent call last): 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 223, in _call_ 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi result = method(context, **params) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/controllers.py", line 452, in delete_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self.token_provider_api.revoke_token(token_id) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 485, in revoke_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self._persistence.delete_token(token_id=token_id) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/persistence/core.py", line 106, in delete_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self.driver.delete_token(unique_id) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/persistence/backends/kvs.py", line 254, in delete_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self._add_to_revocation_list(data, lock) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/kvs/core.py", line 405, in _exit_ 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self.release() 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/kvs/core.py", line 398, in release 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi if not self.expired: 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/kvs/core.py", line 389, in expired 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi if self.mutex.lock_timeout == 0: 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi AttributeError: 'LuaLock' object has no attribute 'lock_timeout' 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: New ** Changed in: keystone Assignee: (unassigned) => Alexander Makarov (amakarov) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1417737 Title: KVS cache backend incompatible with redis-py Status in OpenStack Identity (Keystone): New Bug description: Created Redis cache backend: https://review.openstack.org/#/c/150844/ Tempest revealed problem with locking: <11>Feb 3 14:56:14 node-27 keystone-all 'LuaLock' object has no attribute 'lock_timeout' 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi Traceback (most recent call last): 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 223, in _call_ 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi result = method(context, **params) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/controllers.py", line 452, in delete_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self.token_provider_api.revoke_token(token_id) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 485, in revoke_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self._persistence.delete_token(token_id=token_id) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/persistence/core.py", line 106, in delete_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self.driver.delete_token(unique_id) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/persistence/backends/kvs.py", line 254, in delete_token 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self._add_to_revocation_list(data, lock) 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/kvs/core.py", line 405, in _exit_ 2015-02-03 14:56:14.890 8959 TRACE keystone.common.wsgi self.release() 2015-02-03 14:56:14.890 8959 T
[Yahoo-eng-team] [Bug 1412846] [NEW] Cannot chain a trust with a role specified by name
Public bug reported:
>From comment in https://review.openstack.org/#/c/126897/
Hi! The new feature is great, but (unless I did a mistake somewhere) I
cannot create a chained trust specifying roles with "name" as opposed to
"id".
Here's a sample trust POST:
{"trust":{"trustor_user_id":"...","trustee_user_id":"...","project_id":"...","impersonation":true,"roles":[{"name":"admin"}]}}
And an accompanying traceback:
2015-01-19 17:12:36.953 4246 ERROR keystone.common.wsgi [-] 'id'
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi Traceback (most recent
call last):
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 223, in
__call__
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi result =
method(context, **params)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 158, in
inner
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi return f(self,
context, *args, **kwargs)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/validation/__init__.py", line
36, in wrapper
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi return func(*args,
**kwargs)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/trust/controllers.py", line 163, in
create_trust
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi redelegated_trust)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/notifications.py", line 93, in
wrapper
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi result = f(*args,
**kwargs)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/trust/core.py", line 165, in
create_trust
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi
self._validate_redelegation(t, trust)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/trust/core.py", line 85, in
_validate_redelegation
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi if not
all(role['id'] in parent_roles for role in trust['roles']):
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/trust/core.py", line 85, in
<genexpr>
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi if not
all(role['id'] in parent_roles for role in trust['roles']):
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi KeyError: 'id'
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi
** Affects: keystone
Importance: Undecided
Assignee: Alexander Makarov (amakarov)
Status: New
** Changed in: keystone
Assignee: (unassigned) => Alexander Makarov (amakarov)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1412846
Title:
Cannot chain a trust with a role specified by name
Status in OpenStack Identity (Keystone):
New
Bug description:
From comment in https://review.openstack.org/#/c/126897/
Hi! The new feature is great, but (unless I did a mistake somewhere) I
cannot create a chained trust specifying roles with "name" as opposed
to "id".
Here's a sample trust POST:
{"trust":{"trustor_user_id":"...","trustee_user_id":"...","project_id":"...","impersonation":true,"roles":[{"name":"admin"}]}}
And an accompanying traceback:
2015-01-19 17:12:36.953 4246 ERROR keystone.common.wsgi [-] 'id'
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi Traceback (most
recent call last):
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 223, in
__call__
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi result =
method(context, **params)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 158, in
inner
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi return f(self,
context, *args, **kwargs)
2015-01-19 17:12:36.953 4246 TRACE keystone.common.wsgi File
"/usr/lib/python2.7/site-packages/keystone/common/validation/__init__.py", line
36, in wrapper
2015-01-19 17:12:36.953 4246 TRACE keystone.common.ws
[Yahoo-eng-team] [Bug 1403929] [NEW] Improve clarity, encapsulation and performance of assignment type calculation
Public bug reported: There is an assignment type calculation function in: https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L121-L135, which is better to be implemented as an AssignmentType classmethod. ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Alexander Makarov (amakarov) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1403929 Title: Improve clarity, encapsulation and performance of assignment type calculation Status in OpenStack Identity (Keystone): In Progress Bug description: There is an assignment type calculation function in: https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L121-L135, which is better to be implemented as an AssignmentType classmethod. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1403929/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1402760] [NEW] All user tokens are considered revoked on it's group role revocation
Public bug reported: The case for the bug: - User authenticates and receives a token scoped to the project1 - User authenticates and receives a token scoped to the project2 - User joins the group - Group is granted a role to the project1 - Group role grant to the project1 is revoked Result: All user tokens are considered revoked. Analysis: Revoke model lacks correct token by group revocation - it is done through revocation by user, what results in described effect. ** Affects: keystone Importance: Undecided Assignee: Haneef Ali (haneef) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1402760 Title: All user tokens are considered revoked on it's group role revocation Status in OpenStack Identity (Keystone): In Progress Bug description: The case for the bug: - User authenticates and receives a token scoped to the project1 - User authenticates and receives a token scoped to the project2 - User joins the group - Group is granted a role to the project1 - Group role grant to the project1 is revoked Result: All user tokens are considered revoked. Analysis: Revoke model lacks correct token by group revocation - it is done through revocation by user, what results in described effect. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1402760/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1401926] [NEW] Role revocation invalidates tokens on all user projects
Public bug reported: Keystone invalidates every token for a user after changing its roles within one project. This was reported by Horizon team, here are related bugs: - https://bugs.launchpad.net/mos/+bug/1393732 - https://bugs.launchpad.net/horizon/+bug/1252341 After some debugging I discovered, that it looks like revocation extension bug: I added this test case to tests.test_v3_auth.TestTokenRevokeById http://paste.openstack.org/show/149939/ It assigns role to user on 2 different project, authorizes user on those projects, revokes the role from one of the projects. Token to the other, "intact" project, seizes to validate. Further investigation gave me that token is not deleted, but a revocation event created matching both tokens. ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1401926 Title: Role revocation invalidates tokens on all user projects Status in OpenStack Identity (Keystone): In Progress Bug description: Keystone invalidates every token for a user after changing its roles within one project. This was reported by Horizon team, here are related bugs: - https://bugs.launchpad.net/mos/+bug/1393732 - https://bugs.launchpad.net/horizon/+bug/1252341 After some debugging I discovered, that it looks like revocation extension bug: I added this test case to tests.test_v3_auth.TestTokenRevokeById http://paste.openstack.org/show/149939/ It assigns role to user on 2 different project, authorizes user on those projects, revokes the role from one of the projects. Token to the other, "intact" project, seizes to validate. Further investigation gave me that token is not deleted, but a revocation event created matching both tokens. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1401926/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1401108] [NEW] Memcache pool locks on release
Public bug reported: At some point Keystone stops processing HTTP requests and HAProxy moves the server out of pool. Once Keystones on all controllers stuck HAProxy starts to respond with HTTP 503 error. Symptoms: ~ HAProxy log: 2014-12-08T11:01:06.135849+00:00 info: 192.168.0.23:34984 [08/Dec/2014:11:01:06.135] keystone-2 keystone-2/ 0/-1/-1/-1/0 503 212 - - SC-- 366/0/0/0/0 0/0 "POST /v2.0/tokens HTTP/1.1" Keystone keeps accepting TCP connection, but hangs at HTTP level (meaning that telnet works, but curl hangs) root@node-21:/var/log/keystone# strace -p 26330 Process 26330 attached - interrupt to quit futex(0xe50420, FUTEX_WAIT_PRIVATE, 0, NULL The last logged message from stuck process: 2014-12-05 17:01:20.749 26330 DEBUG keystone.common.cache._memcache_pool [-] Memcached pool 39391504, thread 139781728069376: Acquiring connection _debug_logger /usr/lib/python2.7/dist-packages/keystone/common/cache/_memcache_pool.py:91 Memcache pool has asymmetric behaviour on aquire and release of a connection: If pool is depleted a new connection is created If pool has reached it's maximum size that connection excess still being pushed back to the pool causing thread lock. ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: New ** Changed in: keystone Assignee: (unassigned) => Alexander Makarov (amakarov) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1401108 Title: Memcache pool locks on release Status in OpenStack Identity (Keystone): New Bug description: At some point Keystone stops processing HTTP requests and HAProxy moves the server out of pool. Once Keystones on all controllers stuck HAProxy starts to respond with HTTP 503 error. Symptoms: ~ HAProxy log: 2014-12-08T11:01:06.135849+00:00 info: 192.168.0.23:34984 [08/Dec/2014:11:01:06.135] keystone-2 keystone-2/ 0/-1/-1/-1/0 503 212 - - SC-- 366/0/0/0/0 0/0 "POST /v2.0/tokens HTTP/1.1" Keystone keeps accepting TCP connection, but hangs at HTTP level (meaning that telnet works, but curl hangs) root@node-21:/var/log/keystone# strace -p 26330 Process 26330 attached - interrupt to quit futex(0xe50420, FUTEX_WAIT_PRIVATE, 0, NULL The last logged message from stuck process: 2014-12-05 17:01:20.749 26330 DEBUG keystone.common.cache._memcache_pool [-] Memcached pool 39391504, thread 139781728069376: Acquiring connection _debug_logger /usr/lib/python2.7/dist-packages/keystone/common/cache/_memcache_pool.py:91 Memcache pool has asymmetric behaviour on aquire and release of a connection: If pool is depleted a new connection is created If pool has reached it's maximum size that connection excess still being pushed back to the pool causing thread lock. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1401108/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1395688] [NEW] Memcache distributed lock ruins HA
Public bug reported: Current memcache lock's polling interval calculation locks execution for too long. In concurrent environment when distributed locking is actively used the chance of 8 subsequent lock collisions is high enough to begin failing authorisation due to timeout. ** Affects: keystone Importance: Undecided Status: New ** Tags: performance -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1395688 Title: Memcache distributed lock ruins HA Status in OpenStack Identity (Keystone): New Bug description: Current memcache lock's polling interval calculation locks execution for too long. In concurrent environment when distributed locking is actively used the chance of 8 subsequent lock collisions is high enough to begin failing authorisation due to timeout. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1395688/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1388069] [NEW] Review documentation change for trust redelegation
Public bug reported: https://review.openstack.org/#/c/131541/ needs a tech. writer review. ** Affects: keystone Importance: Undecided Assignee: Irina (ipovolotskaya) Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1388069 Title: Review documentation change for trust redelegation Status in OpenStack Identity (Keystone): New Bug description: https://review.openstack.org/#/c/131541/ needs a tech. writer review. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1388069/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1380670] [NEW] python-memcached misses working backend
Public bug reported: In multi-backend case there is always a chance for client to miss a working backend among not responding. Assuming memcached is up and running on localhost:11211: import memcache import random cl = memcache.Client(['localhost:11211', 'localhost:11212', 'localhost:11213', 'localhost:11214']) while cl.set(str(random.random()), 1): pass 'while' must be an infinite loop since cl.set() returns True on success but it exits in milliseconds instead. Bug may be fixed by changing backend selection logic, patch attached. ** Affects: keystone Importance: Undecided Status: New ** Patch added: "MIRA0001-get_server_fix.patch" https://bugs.launchpad.net/bugs/1380670/+attachment/4234454/+files/MIRA0001-get_server_fix.patch ** Description changed: - In multi-backend case there always a chance for client to miss a working - backend among not responding. + In multi-backend case there is always a chance for client to miss a + working backend among not responding. Assuming memcached is up and running on localhost:11211: import memcache import random cl = memcache.Client(['localhost:11211', 'localhost:11212', 'localhost:11213', 'localhost:11214']) while cl.set(str(random.random()), 1): pass 'while' must be an infinite loop since cl.set() returns True on success but it exits in milliseconds instead. Bug may be fixed by changing backend selection logic, patch attached. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1380670 Title: python-memcached misses working backend Status in OpenStack Identity (Keystone): New Bug description: In multi-backend case there is always a chance for client to miss a working backend among not responding. Assuming memcached is up and running on localhost:11211: import memcache import random cl = memcache.Client(['localhost:11211', 'localhost:11212', 'localhost:11213', 'localhost:11214']) while cl.set(str(random.random()), 1): pass 'while' must be an infinite loop since cl.set() returns True on success but it exits in milliseconds instead. Bug may be fixed by changing backend selection logic, patch attached. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1380670/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1377080] Re: Stale endpoint selection logic in keystone client
** Changed in: keystone Assignee: (unassigned) => Alexander Makarov (amakarov) ** Project changed: keystone => python-keystoneclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1377080 Title: Stale endpoint selection logic in keystone client Status in Python client library for Keystone: New Bug description: In V3 endpoint groups from different regions are not grouped. It results in a problem in "url_for": it only stores for result endpoints of the last region of all with similar service type. To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1377080/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1377080] [NEW] Stale endpoint selection logic in keystone client
Public bug reported: In V3 endpoint groups from different regions are not grouped. It results in a problem in "url_for": it only stores for result endpoints of the last region of all with similar service type. ** Affects: keystone Importance: Undecided Assignee: Alexander Makarov (amakarov) Status: New ** Tags: catalog ** Summary changed: - Stale endpoint group selection logic in keystone client + Stale endpoint selection logic in keystone client -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1377080 Title: Stale endpoint selection logic in keystone client Status in OpenStack Identity (Keystone): New Bug description: In V3 endpoint groups from different regions are not grouped. It results in a problem in "url_for": it only stores for result endpoints of the last region of all with similar service type. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1377080/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
