[Yahoo-eng-team] [Bug 1634568] Re: [api] Inconsistency between v3 API and keystone token timestamps

[Brant Knudson]

https://review.openstack.org/#/c/413878/ didn't fix the problem. The
timestamps in the v3 token issue response still doesn't match the spec
as described in the bug description.

** Changed in: keystone
   Status: Fix Released => New

** Changed in: keystone
Milestone: ocata-3 => None

-- 
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/1634568

Title:
  [api] Inconsistency between v3 API and keystone token timestamps

Status in OpenStack Identity (keystone):
  New

Bug description:
  The v3 API spec for tokens documents the format of timestamps[1]. It
  says the format is like "CCYY-MM-DDThh:mm:ss±hh:mm".

  By this, the timestamps returned by keystone should be like
  2016-10-17T15:17:03+00:00. But they actually show up like this:

  V3:
  "issued_at": "2016-10-17T15:17:03.00Z",
  "expires_at": "2016-10-17T16:17:03.00Z",

  V2:
  "issued_at": "2016-10-17T15:17:56.00Z",
  "expires": "2016-10-17T16:17:56Z",

  Tempest has checks that the timestamp ends in Z.

  [1] http://developer.openstack.org/api-ref/identity/v3/?expanded
  =validate-and-show-information-for-token-detail#id19

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1634568/+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 1634568] Re: Inconsistency between v3 API and keystone token timestamps

[Brant Knudson]

The v3 documentation is still incorrect.

** Changed in: keystone
   Status: Invalid => 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/1634568

Title:
  Inconsistency between v3 API and keystone token timestamps

Status in OpenStack Identity (keystone):
  New

Bug description:
  The v3 API spec for tokens documents the format of timestamps[1]. It
  says the format is like "CCYY-MM-DDThh:mm:ss±hh:mm".

  By this, the timestamps returned by keystone should be like
  2016-10-17T15:17:03+00:00. But they actually show up like this:

  V3:
  "issued_at": "2016-10-17T15:17:03.00Z",
  "expires_at": "2016-10-17T16:17:03.00Z",

  V2:
  "issued_at": "2016-10-17T15:17:56.00Z",
  "expires": "2016-10-17T16:17:56Z",

  Tempest has checks that the timestamp ends in Z.

  [1] http://developer.openstack.org/api-ref/identity/v3/?expanded
  =validate-and-show-information-for-token-detail#id19

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1634568/+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 1615111] [NEW] Useless log message about encryption key loading.

[Brant Knudson]

Public bug reported:


When running keystone with fernet enabled I get a lot of log messages like this:

 2016-08-16 19:54:28.782 2417 INFO keystone.token.providers.fernet.utils
[req-1bbe529c-2513-487b-ac4e-e7ee42fe397a - - - - -] Loaded 2 encryption
keys (max_active_keys=3) from: /etc/keystone/fernet-keys/


There's no point to this being at info level. What am I as an operator supposed 
to do about it?

Why are the keys being loaded all the time? Seems like it would be
faster to cache them.

** 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/1615111

Title:
  Useless log message about encryption key loading.

Status in OpenStack Identity (keystone):
  New

Bug description:
  
  When running keystone with fernet enabled I get a lot of log messages like 
this:

   2016-08-16 19:54:28.782 2417 INFO
  keystone.token.providers.fernet.utils [req-1bbe529c-2513-487b-ac4e-
  e7ee42fe397a - - - - -] Loaded 2 encryption keys (max_active_keys=3)
  from: /etc/keystone/fernet-keys/

  
  There's no point to this being at info level. What am I as an operator 
supposed to do about it?

  Why are the keys being loaded all the time? Seems like it would be
  faster to cache them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1615111/+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 1610409] Re: s.u.p.p.o.r.t @.1800, 6817 208 @ HUSHMAIL s.u.p.p.o.r.t P.h.o.n.e N.u.m.b.e.r HUSHMAIL t.e.c.hnical s.u.p.p.o.rt n.u.m.b.e.r HUSHMAIL c.u.s.t.o.m.e.r s.u.p.p.o.r.t p

[Brant Knudson]

** Changed in: keystone
   Status: New => Invalid

-- 
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/1610409

Title:
  s.u.p.p.o.r.t @.1800,6817 208 @ HUSHMAIL s.u.p.p.o.r.t P.h.o.n.e
  N.u.m.b.e.r HUSHMAIL t.e.c.hnical s.u.p.p.o.rt n.u.m.b.e.r HUSHMAIL
  c.u.s.t.o.m.e.r s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Support & Service Call -)) 1800 681 7208 )))HUSHMAIL Tech support
  phone number HUSHMAIL support Phone number  %%2$$ HUSHMAIL customer
  support phone number +1800-681-7208 HUSHMAIL customer service
  number,1800^681^7208 HUSHMAIL helpdesk phone number, HUSHMAIL customer
  care number, 1800*681*7208 HUSHMAIL support phone number, HUSHMAIL
  password recovery phone number, 1800::681::7208 HUSHMAIL customer care
  phone number, HUSHMAIL customer service number HUSHMAIL official phone
  number 1800**681**7208 @$@$

  +1800 681 7208 HUSHMAIL MAIL SUPPORT NUMBER 1800 681 7208 HUSHMAIL
  customer care number HUSHMAIL support phone number 1800 681 7208
  HUSHMAIL customer care number 1800 681 7208 HUSHMAIL helpdesk phone
  number 1800 681 7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL Mail
  helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL tech
  support number 1800 681 7208 HUSHMAIL Technical support number
  1800-681-7208 HUSHMAIL MAIL SUPPORT NUMBER 1800-681-7208 HUSHMAIL
  customer care number HUSHMAIL support phone number 1800-681-7208
  HUSHMAIL customer care number 1800-681-7208 HUSHMAIL helpdesk phone
  number 1800-681-7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL Mail
  helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL tech
  support number 1800-681-7208 HUSHMAIL Technical support number
  @@/CANADA +1800 681 7208 HUSHMAIL MAIL SUPPORT NUMBER 1800 681 7208
  HUSHMAIL customer care number HUSHMAIL support phone number 1800 681
  7208 HUSHMAIL customer care number 1800 681 7208 HUSHMAIL helpdesk
  phone number 1800 681 7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL
  Mail helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL
  tech support number 1800 681 7208 HUSHMAIL Technical support number
  1800-681-7208 HUSHMAIL MAIL SUPPORT NUMBER 1800-681-7208 HUSHMAIL
  customer care number HUSHMAIL support phone number 1800-681-7208
  HUSHMAIL customer care number 1800-681-7208 HUSHMAIL helpdesk phone
  number 1800-681-7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL Mail
  helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL tech
  support number 1800-681-7208 HUSHMAIL Technical support number
  @@/CANADA +1800 681 7208 HUSHMAIL MAIL SUPPORT NUMBER 1800 681 7208
  HUSHMAIL customer care number HUSHMAIL support phone number 1800 681
  7208 HUSHMAIL customer care number 1800 681 7208 HUSHMAIL helpdesk
  phone number 1800 681 7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL
  Mail helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL
  tech support number 1800 681 7208 HUSHMAIL Technical support number
  1800-681-7208 HUSHMAIL MAIL SUPPORT NUMBER 1800-681-7208 HUSHMAIL
  customer care number HUSHMAIL support phone number 1800-681-7208
  HUSHMAIL customer care number 1800-681-7208 HUSHMAIL helpdesk phone
  number 1800-681-7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL Mail
  helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL tech
  support number 1800-681-7208 HUSHMAIL Technical support number
  @@/CANADA +1800 681 7208 HUSHMAIL MAIL SUPPORT NUMBER 1800 681 7208
  HUSHMAIL customer care number HUSHMAIL support phone number 1800 681
  7208 HUSHMAIL customer care number 1800 681 7208 HUSHMAIL helpdesk
  phone number 1800 681 7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL
  Mail helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL
  tech support number 1800 681 7208 HUSHMAIL Technical support number
  1800-681-7208 HUSHMAIL MAIL SUPPORT NUMBER 1800-681-7208 HUSHMAIL
  customer care number HUSHMAIL support phone number 1800-681-7208
  HUSHMAIL customer care number 1800-681-7208 HUSHMAIL helpdesk phone
  number 1800-681-7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL Mail
  helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL tech
  support number 1800-681-7208 HUSHMAIL Technical support number
  @@/CANADA +1800 681 7208 HUSHMAIL MAIL SUPPORT NUMBER 1800 681 7208
  HUSHMAIL customer care number HUSHMAIL support phone number 1800 681
  7208 HUSHMAIL customer care number 1800 681 7208 HUSHMAIL helpdesk
  phone number 1800 681 7208 HUSHMAIL MAIL SUPPORT HELPDESK HUSHMAIL
  Mail helpdesk number HUSHMAIL Password recovery phone number HUSHMAIL
  tech support number 1800 681 7208 HUSHMAIL Technical support number
  1800-681-7208 HUSHMAIL MAIL SUPPORT NUMBER 1800-681-7208 HUSHMAIL
  customer care number HUSHMAIL support phone number 1800-681-7208
  HUSHMAIL customer care number 1800-681-7208 HUSHMAIL helpdesk phone
  number 1800-681-7208 

[Yahoo-eng-team] [Bug 1609566] [NEW] 500 error from revocation event deserialize

[Brant Knudson]

Public bug reported:


Sometimes in our deployment we get a 500 error from token validation. 

Here's the traceback in the log file:

 [req-b9109488-f02c-467e-b89c-44841d3778a3 e9ac624f6cd546eaac4e897371665b73 
293f917033b246ac8d0df7b77db77369 - default default] __init__() keywords must be 
strings
 Traceback (most recent call last):
   File "keystone/local/lib/python2.7/site-packages/keystone/common/wsgi.py", 
line 381, in _inner
 return method(self, request)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/middleware/auth.py", line 
141, in process_request
 resp = super(AuthContextMiddleware, self).process_request(request)
   File 
"keystone/local/lib/python2.7/site-packages/keystonemiddleware/auth_token/__init__.py",
 line 356, in process_request
 data, user_auth_ref = self._do_fetch_token(request.user_token)
   File 
"keystone/local/lib/python2.7/site-packages/keystonemiddleware/auth_token/__init__.py",
 line 396, in _do_fetch_token
 data = self.fetch_token(token)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/middleware/auth.py", line 
52, in fetch_token
 return self.token_provider_api.validate_token(token)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/common/manager.py", line 
124, in wrapped
 __ret_val = __f(*args, **kwargs)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/token/provider.py", line 
215, in validate_token
 self._is_valid_token(token)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/token/provider.py", line 
348, in _is_valid_token
 self.check_revocation(token)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/common/manager.py", line 
124, in wrapped
 __ret_val = __f(*args, **kwargs)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/token/provider.py", line 
270, in check_revocation
 return self.check_revocation_v3(token)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/common/manager.py", line 
124, in wrapped
 __ret_val = __f(*args, **kwargs)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/token/provider.py", line 
263, in check_revocation_v3
 self.revoke_api.check_token(token_values)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/common/manager.py", line 
124, in wrapped
 __ret_val = __f(*args, **kwargs)
   File "keystone/local/lib/python2.7/site-packages/keystone/revoke/core.py", 
line 207, in check_token
 if revoke_model.is_revoked(self.list_events(), token_values):
   File 
"keystone/local/lib/python2.7/site-packages/keystone/common/manager.py", line 
124, in wrapped
 __ret_val = __f(*args, **kwargs)
   File "keystone/local/lib/python2.7/site-packages/keystone/revoke/core.py", 
line 83, in list_events
 return self._list_events(last_fetch)
   File "keystone/local/lib/python2.7/site-packages/dogpile/cache/region.py", 
line 1053, in decorate
 should_cache_fn)
   File "keystone/local/lib/python2.7/site-packages/dogpile/cache/region.py", 
line 657, in get_or_create
 async_creator) as value:
   File "keystone/local/lib/python2.7/site-packages/dogpile/lock.py", line 154, 
in __enter__
 return self._enter()
   File "keystone/local/lib/python2.7/site-packages/dogpile/lock.py", line 87, 
in _enter
 value = value_fn()
   File "keystone/local/lib/python2.7/site-packages/dogpile/cache/region.py", 
line 610, in get_value
 value = self.backend.get(key)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/common/cache/_context_cache.py",
 line 75, in get
 value = self._get_local_cache(key)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/common/cache/_context_cache.py",
 line 59, in _get_local_cache
 value = msgpackutils.loads(value)
   File 
"keystone/local/lib/python2.7/site-packages/oslo_serialization/msgpackutils.py",
 line 487, in loads
 return msgpack.unpackb(s, ext_hook=ext_hook, encoding='utf-8')
   File "msgpack/_unpacker.pyx", line 139, in msgpack._unpacker.unpackb 
(msgpack/_unpacker.cpp:139)
   File 
"keystone/local/lib/python2.7/site-packages/oslo_serialization/msgpackutils.py",
 line 401, in _unserializer
 return handler.deserialize(data)
   File 
"keystone/local/lib/python2.7/site-packages/keystone/models/revoke_model.py", 
line 348, in deserialize
 revoke_event = RevokeEvent(**revoke_event_data)
 TypeError: __init__() keywords must be strings

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1609566

Title:

[Yahoo-eng-team] [Bug 1590179] [NEW] fernet memcache performance regression

[Brant Knudson]

Public bug reported:


Fernet token validation performance got worse in mitaka vs in liberty. This is 
because it's not using memcache to cache the token anymore.

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: fernet

-- 
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/1590179

Title:
  fernet memcache performance regression

Status in OpenStack Identity (keystone):
  New

Bug description:
  
  Fernet token validation performance got worse in mitaka vs in liberty. This 
is because it's not using memcache to cache the token anymore.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1590179/+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 1563101] Re: Remove backend dependency on core

[Brant Knudson]

The core shouldn't know about the backends. Each backend is optional so
the backend might not even be available.

** Changed in: keystone
   Status: In Progress => Opinion

-- 
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/1563101

Title:
  Remove backend dependency on core

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  Remove dependencies where backend code references code in the core.  For 
example, identity backends imports identity:
  
https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L24

  The reasoning being that the core should know about the backends, but
  the backends should not know anything about the core (separation of
  concerns).

  And part of the risk here is a potential for circular dependencies.
  Backend code could reference code in the core, as well as other higher
  level modules inside identity; thus, creating a circular dependency.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1563101/+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 1550017] [NEW] keystone eventlet using session is in 'prepared' state

[Brant Knudson]

Public bug reported:


http://logs.openstack.org/58/257458/5/check/gate-tempest-dsvm-keystone-eventlet-full/2441200/logs/screen-key.txt.gz#_2016-02-24_17_26_26_453

Many operations are failing with an exception:

This session is in 'prepared' state; no further SQL can be emitted
within this transaction.

Traceback (most recent call last):
  File "/opt/stack/new/keystone/keystone/common/wsgi.py", line 250, in __call__
result = method(context, **params)
  File "/usr/local/lib/python2.7/dist-packages/oslo_log/versionutils.py", line 
165, in wrapped
return func_or_cls(*args, **kwargs)
  File "/opt/stack/new/keystone/keystone/token/controllers.py", line 100, in 
authenticate
context, auth)
  File "/opt/stack/new/keystone/keystone/token/controllers.py", line 302, in 
_authenticate_local
password=password)
  File "/opt/stack/new/keystone/keystone/common/manager.py", line 124, in 
wrapped
__ret_val = __f(*args, **kwargs)
  File "/opt/stack/new/keystone/keystone/notifications.py", line 558, in wrapper
result = f(wrapped_self, context, user_id, *args, **kwargs)
  File "/opt/stack/new/keystone/keystone/identity/core.py", line 425, in wrapper
return f(self, *args, **kwargs)
  File "/opt/stack/new/keystone/keystone/identity/core.py", line 435, in wrapper
return f(self, *args, **kwargs)
  File "/opt/stack/new/keystone/keystone/identity/core.py", line 841, in 
authenticate
ref = driver.authenticate(entity_id, password)
  File "/opt/stack/new/keystone/keystone/identity/backends/sql.py", line 184, 
in authenticate
user_ref = self._get_user(session, user_id)
  File "/opt/stack/new/keystone/keystone/identity/backends/sql.py", line 209, 
in _get_user
user_ref = session.query(User).get(user_id)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 
831, in get
return self._get_impl(ident, loading.load_on_ident)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 
864, in _get_impl
return fallback_fn(self, key)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/loading.py", line 
219, in load_on_ident
return q.one()
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 
2693, in one
ret = list(self)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 
2736, in __iter__
return self._execute_and_instances(context)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 
2749, in _execute_and_instances
close_with_result=True)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line 
2740, in _connection_from_session
**kw)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 
893, in connection
execution_options=execution_options)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 
898, in _connection_for_bind
engine, execution_options)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 
313, in _connection_for_bind
self._assert_active()
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 
202, in _assert_active
"This session is in 'prepared' state; no further "
InvalidRequestError: This session is in 'prepared' state; no further SQL can be 
emitted within this transaction.
2016-02-24 17:26:26.458 14573 ERROR keystone.common.wsgi

Seems like this is related to https://review.openstack.org/#/c/257458/ ,
Use the new enginefacade from oslo.db

** 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/1550017

Title:
  keystone eventlet using session is in 'prepared' state

Status in OpenStack Identity (keystone):
  New

Bug description:
  
  
http://logs.openstack.org/58/257458/5/check/gate-tempest-dsvm-keystone-eventlet-full/2441200/logs/screen-key.txt.gz#_2016-02-24_17_26_26_453

  Many operations are failing with an exception:

  This session is in 'prepared' state; no further SQL can be emitted
  within this transaction.

  Traceback (most recent call last):
File "/opt/stack/new/keystone/keystone/common/wsgi.py", line 250, in 
__call__
  result = method(context, **params)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/versionutils.py", 
line 165, in wrapped
  return func_or_cls(*args, **kwargs)
File "/opt/stack/new/keystone/keystone/token/controllers.py", line 100, in 
authenticate
  context, auth)
File "/opt/stack/new/keystone/keystone/token/controllers.py", line 302, in 
_authenticate_local
  password=password)
File "/opt/stack/new/keystone/keystone/common/manager.py", line 124, in 
wrapped
  __ret_val = __f(*args, **kwargs)
File "/opt/stack/new/keystone/keystone/notifications.py", line 558, in 
wrapper
  result = f(wrapped_self, context, 

[Yahoo-eng-team] [Bug 1549371] [NEW] Deprecation message when using default keystone-paste.ini

[Brant Knudson]

Public bug reported:


When configured using the default keystone-paste.ini and the admin token is 
used, keystone prints a warning:

2016-02-24 10:29:04.810 WARNING keystone.middleware.auth [req-b55760b6
-94fd-4ae6-8373-951a33bbd7b1  ] Deprecated: Auth context checking for
the admin token is deprecated as of the Mitaka release and will be
removed in the O release. Update keystone-paste.ini so that
admin_token_auth is before build_auth_context in the paste pipelines.

The default keystone-paste.ini should be corrected so that this warning
isn't printed.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1549371

Title:
  Deprecation message when using default keystone-paste.ini

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  
  When configured using the default keystone-paste.ini and the admin token is 
used, keystone prints a warning:

  2016-02-24 10:29:04.810 WARNING keystone.middleware.auth [req-b55760b6
  -94fd-4ae6-8373-951a33bbd7b1  ] Deprecated: Auth context checking for
  the admin token is deprecated as of the Mitaka release and will be
  removed in the O release. Update keystone-paste.ini so that
  admin_token_auth is before build_auth_context in the paste pipelines.

  The default keystone-paste.ini should be corrected so that this
  warning isn't printed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1549371/+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 1548562] [NEW] Misleading response when try to delete project with children

[Brant Knudson]

Public bug reported:


When attempting to delete a project that has a child, the operation
is rejected as expected, but the message says it was rejected
because of an authority problem:

 You are not authorized to perform the requested action: cannot
 delete the project ... since it is not a leaf in the hierarchy.

This is misleading since the problem has nothing to do with
authority and granting more authority isn't going to allow the
operation to work.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1548562

Title:
  Misleading response when try to delete project with children

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  
  When attempting to delete a project that has a child, the operation
  is rejected as expected, but the message says it was rejected
  because of an authority problem:

   You are not authorized to perform the requested action: cannot
   delete the project ... since it is not a leaf in the hierarchy.

  This is misleading since the problem has nothing to do with
  authority and granting more authority isn't going to allow the
  operation to work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1548562/+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 1547214] [NEW] Domain created by keystone-manage bootstrap has no description

[Brant Knudson]

Public bug reported:


When keystone-manage bootstrap creates a domain it doesn't have a description. 
Normally the description is like "Owns users and tenants (i.e. projects) 
available on Identity API v2."

Testing this requires that the default domain isn't created by keystone-
manage db_sync, which it normally is.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1547214

Title:
  Domain created by keystone-manage bootstrap has no description

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  
  When keystone-manage bootstrap creates a domain it doesn't have a 
description. Normally the description is like "Owns users and tenants (i.e. 
projects) available on Identity API v2."

  Testing this requires that the default domain isn't created by
  keystone-manage db_sync, which it normally is.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1547214/+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 1488208] Re: Revoking a role assignment revokes unscoped tokens too

[Brant Knudson]

** Changed in: keystone/kilo
   Status: Fix Released => 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/1488208

Title:
  Revoking a role assignment revokes unscoped tokens too

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  In Progress

Bug description:
  When you delete a role assignment using a user+role+project pairing,
  unscoped tokens between the user+project are unnecessarily revoked as
  well. In fact, two events are created for each role assignment
  deletion (one that is scoped correctly and one that is scoped too
  broadly).

  The test failure in https://review.openstack.org/#/c/216236/
  illustrates this issue:

http://logs.openstack.org/36/216236/1/check/gate-keystone-
  python27/3f44af1/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1488208/+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 1317302] Re: pki_setup shouldn't be required to check revocations

[Brant Knudson]

The revocation list is signed by the PKI certificates for some reason.
The revocation list is used for UUID tokens in addition to PKI tokens.

This fix is making it so that the revocation list is not signed by the
PKI certificates.

** Changed in: keystone
   Status: Won't Fix => 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/1317302

Title:
  pki_setup shouldn't be required to check revocations

Status in OpenStack Identity (keystone):
  In Progress
Status in keystonemiddleware:
  In Progress

Bug description:
  
  With the fix for bug 1312858 , auth_token can validate UUID tokens or hashed 
PKI tokens against the revocation list. But in order to use this in a setting 
where only UUID tokens are being used, the server still needs to have pki_setup 
run. We should be able to check UUID tokens against the revocation list even 
when pki_setup hasn't been done.

  The reason pki_setup has to be done is that the revocation list is
  signed using CMS. The auth_token middleware only accepts the signed
  format for the revocation list.

  The proposed solution is to change the auth_token middleware to also
  accept a revocation list that's not signed. If it's not signed, then
  the PKI certificates aren't required.

  The keystone server will be changed to allow configuring it such that
  the revocation list will be sent as an unencrypted JSON object that
  the auth_token middleware can now accept.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1317302/+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 1529193] Re: ec2 credentials create broken in python3

[Brant Knudson]

We've got a blueprint for this, since keystone doesn't claim to support
python 3. https://blueprints.launchpad.net/keystone/+spec/python3

** Changed in: keystone
   Status: New => Won't Fix

-- 
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/1529193

Title:
  ec2 credentials create broken in python3

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  When I run tools/sample_data.sh, it crashed.

  And the server log is:

  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi Traceback (most 
recent call last):
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi   File 
"/home/zsj/Workspace/openstack/keystone/keystone/common/wsgi.py", line 247, in 
__call__
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi result = 
method(context, **params)
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi   File 
"/home/zsj/Workspace/openstack/keystone/keystone/contrib/ec2/controllers.py", 
line 302, in create_credential
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi tenant_id)
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi   File 
"/home/zsj/Workspace/openstack/keystone/keystone/contrib/ec2/controllers.py", 
line 182, in create_credential
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi credential_id = 
utils.hash_access_key(blob['access'])
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi   File 
"/home/zsj/Workspace/openstack/keystone/keystone/common/utils.py", line 118, in 
hash_access_key
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi 
hash_.update(access)
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi TypeError: 
Unicode-objects must be encoded before hashing
  2015-12-25 15:22:50.568 32700 ERROR keystone.common.wsgi

  related files are:
  
https://github.com/openstack/keystone/blob/507003981206440313cc6fd692ef58c748742435/keystone/contrib/ec2/controllers.py#L182
  
https://github.com/openstack/keystone/blob/507003981206440313cc6fd692ef58c748742435/keystone/common/utils.py#L118

  It will call  utils.hash_access_key to generate a hash.
  However it passes a  Unicode-objects to the function.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1529193/+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 1532345] [NEW] enabled emulation query must filter tree dn

[Brant Knudson]

Public bug reported:


If the user_tree_dn is set to something like cn=foo)bar and enabled emulation 
is enabled, the filter that's used to find the user in the enabled emulation 
entry is invalid. The filter will be like "(member=cn=user_id,cn=foo)bar)", 
which is invalid since the ) in foo)bar terminates the () in the filter. The ) 
needs to be escaped when used in a filter.

I assume an exception would be raised so user operations (like getting a
token) would result in a 500.

While it's unlikely that anybody would actually configure their system
this way, might as well fix it.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Brant Knudson (blk-u)

-- 
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/1532345

Title:
  enabled emulation query must filter tree dn

Status in OpenStack Identity (keystone):
  New

Bug description:
  
  If the user_tree_dn is set to something like cn=foo)bar and enabled emulation 
is enabled, the filter that's used to find the user in the enabled emulation 
entry is invalid. The filter will be like "(member=cn=user_id,cn=foo)bar)", 
which is invalid since the ) in foo)bar terminates the () in the filter. The ) 
needs to be escaped when used in a filter.

  I assume an exception would be raised so user operations (like getting
  a token) would result in a 500.

  While it's unlikely that anybody would actually configure their system
  this way, might as well fix it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1532345/+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 1525275] Re: Loading configuration items from keystoneauth is causing warnings

[Brant Knudson]

** Also affects: keystoneauth
   Importance: Undecided
   Status: New

** No longer affects: keystone

-- 
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/1525275

Title:
  Loading configuration items from keystoneauth is causing warnings

Status in keystoneauth:
  New

Bug description:
  Neutron uses the oslo-config-generator to automatically generate
  configuration files.

  Some configuration items are authentication items retrieved from
  keystone like 'domain-id', 'password' etc. These items are retrieved
  in
  https://github.com/openstack/neutron/blob/master/neutron/opts.py#L275.

  The following warnings are now been output when you run the tox target
  to generate config items (tox -e genconfig) or pep8 as it also
  generates the config files:

  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth_type should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth_section should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth-url should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option default-domain-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option default-domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option domain-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option password should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-domain-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option tenant-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option tenant-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option trust-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-domain-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-name should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)

  These warnings may 

[Yahoo-eng-team] [Bug 1513102] [NEW] Useless deprecation message for driver import

[Brant Knudson]

Public bug reported:


When a driver is specified using the full name (as in, the old config file is 
used), for example if I have:

 driver = keystone.contrib.federation.backends.sql.Federation

I get a deprecation warning:

31304 WARNING oslo_log.versionutils [-] Deprecated: direct import of
driver is deprecated as of Liberty in favor of entrypoints and may be
removed in N.

The deprecation warning is pretty useless. It should at least include
the string that was used so that I can figure out what to change.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) => Brant Knudson (blk-u)

-- 
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/1513102

Title:
  Useless deprecation message for driver import

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  
  When a driver is specified using the full name (as in, the old config file is 
used), for example if I have:

   driver = keystone.contrib.federation.backends.sql.Federation

  I get a deprecation warning:

  31304 WARNING oslo_log.versionutils [-] Deprecated: direct import of
  driver is deprecated as of Liberty in favor of entrypoints and may be
  removed in N.

  The deprecation warning is pretty useless. It should at least include
  the string that was used so that I can figure out what to change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1513102/+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 1453419] Re: Remove workaround for db2 dialect primary key issue

[Brant Knudson]

Marking this as invalid since we didn't provide migration 73 with the
problem, it was only in review.

** Changed in: keystone
   Status: In Progress => Fix Released

** Changed in: keystone
   Status: Fix Released => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1453419

Title:
  Remove workaround for db2 dialect primary key issue

Status in Keystone:
  Invalid

Bug description:
  
  Migration 73 has a workaround for ibm_db_sa issue 173 ( 
https://code.google.com/p/ibm-db/issues/detail?id=173 ). Once that issue is 
fixed we can remove the workaround.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1453419/+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 1505326] Re: Unit tests failing with requests 2.8.0

[Brant Knudson]

Marking invalid for keystone since it wasn't actually a bug in keystone.

This was corrected by the release of keystonemiddleware and python-
keystoneclient, unfortunately the release caused a new bug since it
included capping WebOb which wasn't supposed to be in a release, so now
there's new releases. That's bug 1505996 .

** Changed in: keystone
 Assignee: (unassigned) => Brant Knudson (blk-u)

** Changed in: keystone
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1505326

Title:
  Unit tests failing with requests 2.8.0

Status in Keystone:
  Invalid
Status in openstack-ansible:
  In Progress

Bug description:
  
  When the tests are run, a bunch of them fail:

  pkg_resources.ContextualVersionConflict: (requests 2.8.0
  (/home/jenkins/workspace/gate-keystone-
  python27/.tox/py27/lib/python2.7/site-packages),
  Requirement.parse('requests!=2.8.0,>=2.5.2'), set(['oslo.policy']))

  global-requirements has requests!=2.8.0 , but something must be
  pulling in that version of requests!

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1505326/+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 1505326] [NEW] Unit tests failing with requests 2.8.0

[Brant Knudson]

Public bug reported:


When the tests are run, a bunch of them fail:

pkg_resources.ContextualVersionConflict: (requests 2.8.0
(/home/jenkins/workspace/gate-keystone-python27/.tox/py27/lib/python2.7
/site-packages), Requirement.parse('requests!=2.8.0,>=2.5.2'),
set(['oslo.policy']))

global-requirements has requests!=2.8.0 , but something must be pulling
in that version of requests!

** 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/1505326

Title:
  Unit tests failing with requests 2.8.0

Status in Keystone:
  New

Bug description:
  
  When the tests are run, a bunch of them fail:

  pkg_resources.ContextualVersionConflict: (requests 2.8.0
  (/home/jenkins/workspace/gate-keystone-
  python27/.tox/py27/lib/python2.7/site-packages),
  Requirement.parse('requests!=2.8.0,>=2.5.2'), set(['oslo.policy']))

  global-requirements has requests!=2.8.0 , but something must be
  pulling in that version of requests!

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1505326/+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 1505374] [NEW] Unit tests failing with oslo.policy 0.12.0

[Brant Knudson]

Public bug reported:


oslo.policy 0.12.0 was released recently, and this caused a couple keystone 
unit tests to fail. The new release has a change to use requests rather than 
urllib, and keystone's unit tests were assuming that oslo.policy was 
implemented using urllib (by mocking the response).

failing tests:

 keystone.tests.unit.test_policy.PolicyTestCase.test_enforce_http_true
 keystone.tests.unit.test_policy.PolicyTestCase.test_enforce_http_false

Keystone doesn't need to test these internal implementation details of
oslo.policy, let's just assume it works as designed and they have their
own tests.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1505374

Title:
  Unit tests failing with oslo.policy 0.12.0

Status in Keystone:
  New

Bug description:
  
  oslo.policy 0.12.0 was released recently, and this caused a couple keystone 
unit tests to fail. The new release has a change to use requests rather than 
urllib, and keystone's unit tests were assuming that oslo.policy was 
implemented using urllib (by mocking the response).

  failing tests:

   keystone.tests.unit.test_policy.PolicyTestCase.test_enforce_http_true
   keystone.tests.unit.test_policy.PolicyTestCase.test_enforce_http_false

  Keystone doesn't need to test these internal implementation details of
  oslo.policy, let's just assume it works as designed and they have
  their own tests.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1505374/+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 1500509] [NEW] Define paste entrypoints

[Brant Knudson]

Public bug reported:

oslo.middleware middlewares should define the entry points for the
factories.

In setup.cfg:

[entry_points]
paste.filter_factory =
request_id = oslo_middleware:RequestId.factory

(Or whatever you want to call the entrypoint)

Then we can use it in keystone instead of defining our own.

Here's how it's used in keystone:

[filter:request_id]
use = egg:keystone#request_id

So we'd change to "use = egg:oslo.incubator#request_id".

And then eventually we can remove the line from keystone-paste.ini.

** Affects: keystone
 Importance: Wishlist
 Status: New

** Affects: oslo.middleware
 Importance: Undecided
 Status: New

** Also affects: keystone
   Importance: Undecided
   Status: New

** Changed in: keystone
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1500509

Title:
  Define paste entrypoints

Status in Keystone:
  New
Status in oslo.middleware:
  New

Bug description:
  oslo.middleware middlewares should define the entry points for the
  factories.

  In setup.cfg:

  [entry_points]
  paste.filter_factory =
  request_id = oslo_middleware:RequestId.factory

  (Or whatever you want to call the entrypoint)

  Then we can use it in keystone instead of defining our own.

  Here's how it's used in keystone:

  [filter:request_id]
  use = egg:keystone#request_id

  So we'd change to "use = egg:oslo.incubator#request_id".

  And then eventually we can remove the line from keystone-paste.ini.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1500509/+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 1500459] [NEW] Validating federated fernet token loses user domain info

[Brant Knudson]

Public bug reported:


When using UUID tokens, after token validation the user's domain info is filled 
in. For federated ephemeral users the domain ID and name are both the set to 
the [federation].federated_domain_name config value.[1].

When using fernet tokens, the user domain info isn't filled in.

We've got code in keystone that assumes that all users are going to have
the domain info filled in, for example TokenModel raises UnexpectedError
if the user info in the token doesn't have a domain name or ID, and
doesn't provide a way to check if the user has a domain name or ID
first.[2] (Why does keystone have multiple ways to represent a token??)

The domain info should be filled in when using fernet tokens so that it
works like the other providers.

[1]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n589

[2]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/models/token_model.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n112

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1500459

Title:
  Validating federated fernet token loses user domain info

Status in Keystone:
  In Progress

Bug description:
  
  When using UUID tokens, after token validation the user's domain info is 
filled in. For federated ephemeral users the domain ID and name are both the 
set to the [federation].federated_domain_name config value.[1].

  When using fernet tokens, the user domain info isn't filled in.

  We've got code in keystone that assumes that all users are going to
  have the domain info filled in, for example TokenModel raises
  UnexpectedError if the user info in the token doesn't have a domain
  name or ID, and doesn't provide a way to check if the user has a
  domain name or ID first.[2] (Why does keystone have multiple ways to
  represent a token??)

  The domain info should be filled in when using fernet tokens so that
  it works like the other providers.

  [1]
  
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n589

  [2]
  
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/models/token_model.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n112

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1500459/+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 1500222] [NEW] Request info in logs

[Brant Knudson]

Public bug reported:


The oslo.log standard format for log messages includes a bunch of info about 
the request, the user tenant domain user_domain and project_domain

These are included in nova logs.

For keystone, these aren't included in the log for the request and they
should be when available to make it easier for admins to debug issues.

From
http://git.openstack.org/cgit/openstack/oslo.context/tree/oslo_context/context.py?id=f8285a1f3499a308d3e3f98645ddd56a41e593f8#n75
:

self.user_idt_format.format(user=self.user or '-',
tenant=self.tenant or '-',
domain=self.domain or '-',
user_domain=self.user_domain or '-',
p_domain=self.project_domain or '-'))

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1500222

Title:
  Request info in logs

Status in Keystone:
  New

Bug description:
  
  The oslo.log standard format for log messages includes a bunch of info about 
the request, the user tenant domain user_domain and project_domain

  These are included in nova logs.

  For keystone, these aren't included in the log for the request and
  they should be when available to make it easier for admins to debug
  issues.

  From
  
http://git.openstack.org/cgit/openstack/oslo.context/tree/oslo_context/context.py?id=f8285a1f3499a308d3e3f98645ddd56a41e593f8#n75
  :

  self.user_idt_format.format(user=self.user or '-',
  tenant=self.tenant or '-',
  domain=self.domain or '-',
  user_domain=self.user_domain or '-',
  p_domain=self.project_domain or '-'))

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1500222/+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 1496998] [NEW] fernet token provider is experimental

[Brant Knudson]

Public bug reported:


The fernet token provider is experimental. It's not passing the tempest tests 
that all other providers work with.

- The documentation should say that ther fernet provider is experimental
- If the deployer starts keystone with the fernet provider configured a warning 
message should be logged

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1496998

Title:
  fernet token provider is experimental

Status in Keystone:
  In Progress

Bug description:
  
  The fernet token provider is experimental. It's not passing the tempest tests 
that all other providers work with.

  - The documentation should say that ther fernet provider is experimental
  - If the deployer starts keystone with the fernet provider configured a 
warning message should be logged

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1496998/+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 1496530] [NEW] debug note in error response inaccurate

[Brant Knudson]

Public bug reported:

If I do a GET /v3/auth/tokens with no token and keystone is configured
with debug I get a message back saying I'm not authorized and to disable
debug mode to suppress details:

$ curl http://localhost:5000/v3/auth/tokens
{"error": {"message": "The request you have made requires authentication. 
(Disable debug mode to suppress these details.)", "code": 401, "title": 
"Unauthorized"}}


If I set debug=False, the message changes:

{"error": {"message": "The request you have made requires
authentication.", "code": 401, "title": "Unauthorized"}}


No details have been suppressed. The only difference is that the note about 
disabling debug mode has been removed. The message shouldn't be saying to 
disable debug mode to suppress details when there's no details to suppress.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1496530

Title:
  debug note in error response inaccurate

Status in Keystone:
  New

Bug description:
  If I do a GET /v3/auth/tokens with no token and keystone is configured
  with debug I get a message back saying I'm not authorized and to
  disable debug mode to suppress details:

  $ curl http://localhost:5000/v3/auth/tokens
  {"error": {"message": "The request you have made requires authentication. 
(Disable debug mode to suppress these details.)", "code": 401, "title": 
"Unauthorized"}}

  
  If I set debug=False, the message changes:

  {"error": {"message": "The request you have made requires
  authentication.", "code": 401, "title": "Unauthorized"}}

  
  No details have been suppressed. The only difference is that the note about 
disabling debug mode has been removed. The message shouldn't be saying to 
disable debug mode to suppress details when there's no details to suppress.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1496530/+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 1496041] [NEW] Document accept requests on base paths rather than separate ports

[Brant Knudson]

Public bug reported:


The identity service is expected to be on ports 5000 and 35357 for historical 
reasons. It's been a dream for some time to have the identity service, along 
with the rest of the OpenStack services, available on a path on the normal HTTP 
port so that we're not polluting the port space so much, and also port 35357 
has problems on Linux since it's in the default ephemeral port range.

With keystone switching to being served by Apache Httpd or some other
full-featured web server (as opposed to eventlet) this is actually
pretty easy to accomplish. Httpd (and other web servers) allows you to
route multiple paths / ports to the wsgi process, so you can have :5000
and :443/identity going to the same place (same with :35357 and
:443/identity_admin), all in the same server.

Keystone ships a sample config file in httpd/wsgi-keystone.conf so we'll
update that to support both the virtual hosts on different ports and
path handling.

If we agree on this we can get some tests going to ensure the rest of
the OpenStack ecosystem is ready by changing devstack to use the new
config.

Eventually we can "deprecate" running identity service on 5000 and 35357
and instead use :443/identity and /identity_admin.

** Affects: keystone
 Importance: Wishlist
 Assignee: Brant Knudson (blk-u)
 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/1496041

Title:
  Document accept requests on base paths rather than separate ports

Status in Keystone:
  In Progress

Bug description:
  
  The identity service is expected to be on ports 5000 and 35357 for historical 
reasons. It's been a dream for some time to have the identity service, along 
with the rest of the OpenStack services, available on a path on the normal HTTP 
port so that we're not polluting the port space so much, and also port 35357 
has problems on Linux since it's in the default ephemeral port range.

  With keystone switching to being served by Apache Httpd or some other
  full-featured web server (as opposed to eventlet) this is actually
  pretty easy to accomplish. Httpd (and other web servers) allows you to
  route multiple paths / ports to the wsgi process, so you can have
  :5000 and :443/identity going to the same place (same with :35357 and
  :443/identity_admin), all in the same server.

  Keystone ships a sample config file in httpd/wsgi-keystone.conf so
  we'll update that to support both the virtual hosts on different ports
  and path handling.

  If we agree on this we can get some tests going to ensure the rest of
  the OpenStack ecosystem is ready by changing devstack to use the new
  config.

  Eventually we can "deprecate" running identity service on 5000 and
  35357 and instead use :443/identity and /identity_admin.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1496041/+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 1494330] [NEW] Requirements update is failing

[Brant Knudson]

Public bug reported:


https://review.openstack.org/#/c/222000/ in keystone is a new requirements 
update that came after https://review.openstack.org/203336 requirements update.

the keystone change is failing, when I run it locally the output
includes:

  error in setup command: Invalid environment marker:
(python_version=='2.7' # MPL)

So it looks like something isn't handling comments in setup.cfg lines,
or comments can't be put in setup.cfg lines.

A couple of options:

1) Remove the comment from the global requirements file.
2) Have the requirements update tool strip comments when updating setup.cfg.

** Affects: keystone
 Importance: Critical
 Assignee: Brant Knudson (blk-u)
 Status: Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1494330

Title:
  Requirements update is failing

Status in Keystone:
  Confirmed

Bug description:
  
  https://review.openstack.org/#/c/222000/ in keystone is a new requirements 
update that came after https://review.openstack.org/203336 requirements update.

  the keystone change is failing, when I run it locally the output
  includes:

error in setup command: Invalid environment marker:
  (python_version=='2.7' # MPL)

  So it looks like something isn't handling comments in setup.cfg lines,
  or comments can't be put in setup.cfg lines.

  A couple of options:

  1) Remove the comment from the global requirements file.
  2) Have the requirements update tool strip comments when updating setup.cfg.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1494330/+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 1490160] [NEW] Unit tests are super slow

[Brant Knudson]

Public bug reported:

The unit tests used to take about 5 minutes on my computer. Now they
take 15 minutes.

The unit tests got much slower when
https://review.openstack.org/#/c/214720/ merged. Initializing the paste
pipeline must take a lot longer with this change.

The tests shouldn't be initializing the paste pipeline for tests that
only need to validate driver / backend / controller behavior.

This affects developer productivity since it takes too long to validate
changes locally.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1490160

Title:
  Unit tests are super slow

Status in Keystone:
  In Progress

Bug description:
  The unit tests used to take about 5 minutes on my computer. Now they
  take 15 minutes.

  The unit tests got much slower when
  https://review.openstack.org/#/c/214720/ merged. Initializing the
  paste pipeline must take a lot longer with this change.

  The tests shouldn't be initializing the paste pipeline for tests that
  only need to validate driver / backend / controller behavior.

  This affects developer productivity since it takes too long to
  validate changes locally.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1490160/+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 1489118] [NEW] Tests fail with local keystone.conf modifications

[Brant Knudson]

Public bug reported:


When there are changes in the local config (/etc/keystone/keystone.conf) some 
tests fail.

For example,
keystone.tests.unit.test_backend_ldap.MultiLDAPandSQLIdentityDomainConfigsInSQL.test_update_user_enable_fails,
fails.

The tests should not be affected by the local config file.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1489118

Title:
  Tests fail with local keystone.conf modifications

Status in Keystone:
  New

Bug description:
  
  When there are changes in the local config (/etc/keystone/keystone.conf) some 
tests fail.

  For example,
  
keystone.tests.unit.test_backend_ldap.MultiLDAPandSQLIdentityDomainConfigsInSQL.test_update_user_enable_fails,
  fails.

  The tests should not be affected by the local config file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1489118/+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 1485604] [NEW] Logs must contain the request ID

[Brant Knudson]

Public bug reported:


The keystone log file doesn't have the request ID like the other projects. The 
log file should contain the request ID so that it's easier to debug.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1485604

Title:
  Logs must contain the request ID

Status in Keystone:
  In Progress

Bug description:
  
  The keystone log file doesn't have the request ID like the other projects. 
The log file should contain the request ID so that it's easier to debug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1485604/+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 1484735] [NEW] Assertion signing error causes TypeError for Message objects do not support addition

[Brant Knudson]

Public bug reported:


If running the xmlsec1 binary fails with some output, rather than getting the 
log of the error you'll get a TypeError exception with the message Message 
objects do not support addition.. This is because oslo.i18n Message objects 
don't support addition, which the code is attempting to do.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1484735

Title:
  Assertion signing error causes TypeError for Message objects do not
  support addition

Status in Keystone:
  New

Bug description:
  
  If running the xmlsec1 binary fails with some output, rather than getting the 
log of the error you'll get a TypeError exception with the message Message 
objects do not support addition.. This is because oslo.i18n Message objects 
don't support addition, which the code is attempting to do.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1484735/+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 1482660] [NEW] Stop using deprecated methods in assignment manager

[Brant Knudson]

Public bug reported:


Keystone code is using a lot of deprecated methods in assignment manager. This 
will cause problems if anybody ever sets fatal_deprecations to True since 
normal operations will just stop working.

You can find the users of the deprecated methods by removing them from
keystone/assignment/core.py and running the tests. The tests should all
work (except for the ones to verify that the deprecated methods are
there).

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1482660

Title:
  Stop using deprecated methods in assignment manager

Status in Keystone:
  In Progress

Bug description:
  
  Keystone code is using a lot of deprecated methods in assignment manager. 
This will cause problems if anybody ever sets fatal_deprecations to True since 
normal operations will just stop working.

  You can find the users of the deprecated methods by removing them from
  keystone/assignment/core.py and running the tests. The tests should
  all work (except for the ones to verify that the deprecated methods
  are there).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1482660/+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 1474069] Re: DeprecatedDecorators test does not setup fixtures correctly

[Brant Knudson]

** Also affects: oslo.log
   Importance: Undecided
   Status: New

** Changed in: oslo.log
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1474069

Title:
  DeprecatedDecorators test does not setup fixtures correctly

Status in Keystone:
  In Progress
Status in oslo.log:
  New

Bug description:
  this test appears to rely upon test suite setup in a different test,
  outside of the test_backend_sql.py suite entirely.Below is a run
  of this specific test, but you get the same error if you run all of
  test_backend_sql at once as well.

  [mbayer@thinkpad keystone]$ tox   -v  -e py27 
keystone.tests.unit.test_backend_sql.DeprecatedDecorators.test_assignment_to_resource_api
  using tox.ini: /home/mbayer/dev/jenkins_scripts/tmp/keystone/tox.ini
  using tox-1.8.1 from /usr/lib/python2.7/site-packages/tox/__init__.pyc
  py27 create: /home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox$ /usr/bin/python 
-mvirtualenv --setuptools --python /usr/bin/python2.7 py27 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/log/py27-0.log
  py27 installdeps: 
-r/home/mbayer/dev/jenkins_scripts/tmp/keystone/requirements.txt, 
-r/home/mbayer/dev/jenkins_scripts/tmp/keystone/test-requirements.txt
/home/mbayer/dev/jenkins_scripts/tmp/keystone$ 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/bin/pip install -U 
-r/home/mbayer/dev/jenkins_scripts/tmp/keystone/requirements.txt 
-r/home/mbayer/dev/jenkins_scripts/tmp/keystone/test-requirements.txt 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/log/py27-1.log
  py27 develop-inst: /home/mbayer/dev/jenkins_scripts/tmp/keystone
/home/mbayer/dev/jenkins_scripts/tmp/keystone$ 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/bin/pip install -U -e 
/home/mbayer/dev/jenkins_scripts/tmp/keystone 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/log/py27-2.log
  py27 runtests: PYTHONHASHSEED='3819984772'
  py27 runtests: commands[0] | bash tools/pretty_tox.sh 
keystone.tests.unit.test_backend_sql.DeprecatedDecorators.test_assignment_to_resource_api
/home/mbayer/dev/jenkins_scripts/tmp/keystone$ /usr/bin/bash 
tools/pretty_tox.sh 
keystone.tests.unit.test_backend_sql.DeprecatedDecorators.test_assignment_to_resource_api
 
  running testr
  running=
  OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
  OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
  OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
  ${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./keystone/tests/unit} --list 
  running=
  OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
  OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
  OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
  ${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./keystone/tests/unit}  --load-list /tmp/tmpclgNWA
  {0} 
keystone.tests.unit.test_backend_sql.DeprecatedDecorators.test_assignment_to_resource_api
 [0.245028s] ... FAILED

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File keystone/tests/unit/test_backend_sql.py, line 995, in 
test_assignment_to_resource_api
  self.config_fixture.config(fatal_deprecations=True)
File 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/lib/python2.7/site-packages/oslo_config/fixture.py,
 line 65, in config
  self.conf.set_override(k, v, group)
File 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/lib/python2.7/site-packages/oslo_config/cfg.py,
 line 1823, in __inner
  result = f(self, *args, **kwargs)
File 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/lib/python2.7/site-packages/oslo_config/cfg.py,
 line 2100, in set_override
  opt_info = self._get_opt_info(name, group)
File 
/home/mbayer/dev/jenkins_scripts/tmp/keystone/.tox/py27/lib/python2.7/site-packages/oslo_config/cfg.py,
 line 2418, in _get_opt_info
  raise NoSuchOptError(opt_name, group)
  oslo_config.cfg.NoSuchOptError: no such option: fatal_deprecations
  

  Captured pythonlogging:
  ~~~
  Adding cache-proxy 'keystone.tests.unit.test_cache.CacheIsolatingProxy' 
to backend.
  registered 'sha512_crypt' handler: class 
'passlib.handlers.sha2_crypt.sha512_crypt'
  

  ==
  Failed 1 tests - output below:
  ==

  
keystone.tests.unit.test_backend_sql.DeprecatedDecorators.test_assignment_to_resource_api
  
-

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File keystone/tests/unit/test_backend_sql.py, line 995, in 
test_assignment_to_resource_api
  self.config_fixture.config(fatal_deprecations=True)
File 
/home/mbayer/dev

[Yahoo-eng-team] [Bug 1482662] [NEW] Remove deprecated methods from assignment manager

[Brant Knudson]

Public bug reported:


The assignment manager doesn't provide a stable interface (yet), so there's no 
need to go through deprecation.

Also, leaving the deprecated methods around makes it too easy for
developers of new features to use the old deprecated method rather than
the new one.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1482662

Title:
  Remove deprecated methods from assignment manager

Status in Keystone:
  In Progress

Bug description:
  
  The assignment manager doesn't provide a stable interface (yet), so there's 
no need to go through deprecation.

  Also, leaving the deprecated methods around makes it too easy for
  developers of new features to use the old deprecated method rather
  than the new one.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1482662/+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 1482687] [NEW] enabled emulation query should request no attributes

[Brant Knudson]

Public bug reported:

When keystone does the ldap_search for the enabled emulation entry, it
asks for the cn attribute to be returned. Since keystone doesn't use
the cn attribute from the result, there's no need for it to request this
attribute, and it would be slightly more efficient to request no
attributes instead since there's less data for the LDAP server to
return.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1482687

Title:
  enabled emulation query should request no attributes

Status in Keystone:
  In Progress

Bug description:
  When keystone does the ldap_search for the enabled emulation entry,
  it asks for the cn attribute to be returned. Since keystone doesn't
  use the cn attribute from the result, there's no need for it to
  request this attribute, and it would be slightly more efficient to
  request no attributes instead since there's less data for the LDAP
  server to return.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1482687/+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 1481048] [NEW] Sample httpd config should have LimitRequestBody

[Brant Knudson]

Public bug reported:


Apache Httpd provides a well-tested way to limit the size of the request body 
via the LimitRequestBody directive, see 
http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody . This is an 
important option for a secure deployment since it prevents clients from 
crashing the server by sending large requests, causing a DoS. As such, 
keystone's sample httpd file should specify LimitRequestBody so that deployers 
know to set it.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1481048

Title:
  Sample httpd config should have LimitRequestBody

Status in Keystone:
  In Progress

Bug description:
  
  Apache Httpd provides a well-tested way to limit the size of the request body 
via the LimitRequestBody directive, see 
http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody . This is an 
important option for a secure deployment since it prevents clients from 
crashing the server by sending large requests, causing a DoS. As such, 
keystone's sample httpd file should specify LimitRequestBody so that deployers 
know to set it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1481048/+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 1479962] [NEW] Use extras for deployment-specific package requirements

[Brant Knudson]

Public bug reported:


Keystone should use extras in setup.cfg for deployment-specific package 
requirements.

One example is ldap.

With this change, deployers can do something like `pip install
keystone[ldap]` to install the packages required for ldap.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1479962

Title:
  Use extras for deployment-specific package requirements

Status in Keystone:
  New

Bug description:
  
  Keystone should use extras in setup.cfg for deployment-specific package 
requirements.

  One example is ldap.

  With this change, deployers can do something like `pip install
  keystone[ldap]` to install the packages required for ldap.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1479962/+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 1479523] [NEW] Stop using debug for insecure responses

[Brant Knudson]

Public bug reported:


If you set debug=true in keystone.conf the server 1) logs at debug level, and 
2) sends out insecure responses. Deployers might think that debug=true only 
does 1, not knowing about 2 since it's not documented in the sample config. The 
behaviors should be decoupled to improve security a bit.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New


** Tags: security

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1479523

Title:
  Stop using debug for insecure responses

Status in Keystone:
  New

Bug description:
  
  If you set debug=true in keystone.conf the server 1) logs at debug level, and 
2) sends out insecure responses. Deployers might think that debug=true only 
does 1, not knowing about 2 since it's not documented in the sample config. The 
behaviors should be decoupled to improve security a bit.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1479523/+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 1468000] Re: Group lookup by name in LDAP via v3 fails

[Brant Knudson]

** Also affects: keystone/kilo
   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/1468000

Title:
  Group lookup by name in LDAP via v3 fails

Status in Keystone:
  Fix Committed
Status in Keystone kilo series:
  New

Bug description:
  This bug is similar to
  https://bugs.launchpad.net/keystone/+bug/1454309 but relates to
  groups. When issuing an openstack group show group_name command on
  a domain associated with LDAP, invalid LDAP query is composed and
  Keystone returns ISE 500:

  $ openstack --os-token ADMIN --os-url http://localhost:35357/v3 
--os-identity-api-version 3 group show --domain ad 'Domain Admins'
  ERROR: openstack An unexpected error prevented the server from fulfilling 
your request: {'desc': 'Bad search filter'} (Disable debug mode to suppress 
these details.) (HTTP 500) (Request-ID: 
req-06fd5907-6ade-4872-95ab-e66f0809986a)

  Here's the log:

  2015-06-23 15:59:41.627 8571 DEBUG keystone.common.ldap.core [-] LDAP search: 
base=CN=Users,DC=dept,DC=example,DC=org scope=2 
filterstr=((None(sAMAccountName=Domain Admins))(objectClass=group)) 
attrs=['cn', 'sAMAccountName', 'description'] attrsonly=0 search_s 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/ldap/core.py:933
  2015-06-23 15:59:41.628 8571 DEBUG keystone.common.ldap.core [-] LDAP unbind 
unbind_s 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/ldap/core.py:906
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi [-] {'desc': 'Bad 
search filter'}
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi Traceback (most 
recent call last):
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/wsgi.py,
 line 240, in __call__
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi result = 
method(context, **params)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/controller.py,
 line 202, in wrapper
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi return f(self, 
context, filters, **kwargs)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/identity/controllers.py,
 line 310, in list_groups
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi hints=hints)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/manager.py,
 line 54, in wrapper
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi return f(self, 
*args, **kwargs)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/identity/core.py,
 line 342, in wrapper
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi return f(self, 
*args, **kwargs)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/identity/core.py,
 line 353, in wrapper
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi return f(self, 
*args, **kwargs)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/identity/core.py,
 line 1003, in list_groups
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi ref_list = 
driver.list_groups(hints)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/identity/backends/ldap.py,
 line 164, in list_groups
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi return 
self.group.get_all_filtered(hints)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/identity/backends/ldap.py,
 line 402, in get_all_filtered
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi for group in 
self.get_all(query)]
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/ldap/core.py,
 line 1507, in get_all
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi for x in 
self._ldap_get_all(ldap_filter)]
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/ldap/core.py,
 line 1469, in _ldap_get_all
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi attrs)
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi   File 
/home/vagrant/.venv/local/lib/python2.7/site-packages/keystone/common/ldap/core.py,
 line 946, in search_s
  2015-06-23 15:59:41.628 8571 ERROR keystone.common.wsgi attrlist_utf8, 
attrsonly)
  2015-06-23 

[Yahoo-eng-team] [Bug 1424496] Re: Documentation lacking for mapping of operation policy target

[Brant Knudson]

Reopening since the previous fix was reverted.

** Changed in: keystone
   Status: Fix Released = In Progress

** Changed in: keystone
Milestone: 2015.1.0 = liberty-2

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1424496

Title:
  Documentation lacking for mapping of operation policy target

Status in Keystone:
  In Progress

Bug description:
  
  There's no documentation that says what the mapping is of target in the 
policy.json file to the operation.

  For example, the policy.json has a target for identity:get_region.
  This is the rule for the operation of GET /v3/regions/{region_id} .
  But there's no way to tell this without reading the code because
  there's no documentation for it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1424496/+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 1473553] [NEW] AuthContextMiddleware re-implements AdminToken

[Brant Knudson]

Public bug reported:


AuthContextMiddleware essentially re-implements the default 
AdminTokenAuthMiddleware:

class AdminTokenAuthMiddleware(wsgi.Middleware):
...
context['is_admin'] = (token == CONF.admin_token)

class AuthContextMiddleware(wsgi.Middleware):
...
if token_id == CONF.admin_token:

The problem is, what if someone decides they want to implement their own
`AdminTokenAuthMiddleware` that implements admin token differently.
For example, using a special client certificate instead.

This should be possible, but it's not because AuthContextMiddleware
decided to re-implement AdminTokenAuthMiddleware rather than using its
output (the setting of is_admin in the context.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1473553

Title:
  AuthContextMiddleware re-implements AdminToken

Status in Keystone:
  In Progress

Bug description:
  
  AuthContextMiddleware essentially re-implements the default 
AdminTokenAuthMiddleware:

  class AdminTokenAuthMiddleware(wsgi.Middleware):
  ...
  context['is_admin'] = (token == CONF.admin_token)

  class AuthContextMiddleware(wsgi.Middleware):
  ...
  if token_id == CONF.admin_token:

  The problem is, what if someone decides they want to implement their
  own `AdminTokenAuthMiddleware` that implements admin token
  differently. For example, using a special client certificate instead.

  This should be possible, but it's not because AuthContextMiddleware
  decided to re-implement AdminTokenAuthMiddleware rather than using its
  output (the setting of is_admin in the context.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1473553/+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 1459828] Re: keystone-all crashes when ca_certs is not defined in conf

[Brant Knudson]

icehouse is now eol, so I don't see any need to spend more time on this.

** Changed in: keystone/icehouse
   Status: Incomplete = Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1459828

Title:
  keystone-all crashes when ca_certs is not defined in conf

Status in Keystone:
  Incomplete
Status in Keystone icehouse series:
  Won't Fix

Bug description:
  When [ssl] ca_certs parameter is commented on keystone.conf, ssl
  module try to load the default ca_cert file
  (/etc/keystone/ssl/certs/ca.pem) and raises an IOError exception
  because it didn't find the file.

  This happens running on Python 2.7.9.

  I have a keystone cluster running on Python 2.7.7, with the very same
  keystone.conf file, and that crash doesn't happen.

  If any further information is required, don't hesitate in contacting
  me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1459828/+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 1469867] [NEW] Stop using deprecated oslo_utils.timeutils.strtime

[Brant Knudson]

Public bug reported:


Keystone unit tests are failing because they're still using the deprecated 
oslo_utils.timeutils.strtime function. We need to stop using the function.

DeprecationWarning: Using function/method
'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and will
be removed in a future version: use either datetime.datetime.isoformat()
or datetime.datetime.strftime() instead

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1469867

Title:
  Stop using deprecated oslo_utils.timeutils.strtime

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  Keystone unit tests are failing because they're still using the deprecated 
oslo_utils.timeutils.strtime function. We need to stop using the function.

  DeprecationWarning: Using function/method
  'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and
  will be removed in a future version: use either
  datetime.datetime.isoformat() or datetime.datetime.strftime() instead

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1469867/+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 1469867] Re: Stop using deprecated oslo_utils.timeutils.strtime

[Brant Knudson]

** Also affects: python-keystoneclient
   Importance: Undecided
   Status: New

** Changed in: python-keystoneclient
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1469867

Title:
  Stop using deprecated oslo_utils.timeutils.strtime

Status in OpenStack Identity (Keystone):
  In Progress
Status in Python client library for Keystone:
  In Progress

Bug description:
  
  Keystone unit tests are failing because they're still using the deprecated 
oslo_utils.timeutils.strtime function. We need to stop using the function.

  DeprecationWarning: Using function/method
  'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and
  will be removed in a future version: use either
  datetime.datetime.isoformat() or datetime.datetime.strftime() instead

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1469867/+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 1469517] [NEW] Federation get_mapping_from_idp_and_protocol should return object

[Brant Knudson]

Public bug reported:


The Federation manager's get_mapping_from_idp_and_protocol method is returning 
a dict where the 'rules' value is a JSON string. That 'rules' is stored as a 
JSON string is an implementation detail that shouldn't be exposed to callers.

The 'rules' value of the dict returned by
get_mapping_from_idp_and_protocol should be JSON-parsed before it's
returned so that callers don't have to know that it's a JSON string.
This way all callers don't have to parse the string themselves.

** 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/1469517

Title:
  Federation get_mapping_from_idp_and_protocol should return object

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  The Federation manager's get_mapping_from_idp_and_protocol method is 
returning a dict where the 'rules' value is a JSON string. That 'rules' is 
stored as a JSON string is an implementation detail that shouldn't be exposed 
to callers.

  The 'rules' value of the dict returned by
  get_mapping_from_idp_and_protocol should be JSON-parsed before it's
  returned so that callers don't have to know that it's a JSON string.
  This way all callers don't have to parse the string themselves.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1469517/+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 1467008] Re: Unit tests fail with sqlalchemy 1.1.0

[Brant Knudson]

** Also affects: oslo.db
   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/1467008

Title:
  Unit tests fail with sqlalchemy 1.1.0

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Oslo Database library:
  New

Bug description:
  
  Unit tests fail with sqlalchemy 1.1.0. See 
https://review.openstack.org/#/c/190405/ , which tries to upgrade the 
requirement and fails.

  2015-06-16 19:32:44.080 | 
keystone.tests.unit.test_sql_upgrade.SqlUpgradeTests.test_region_url_upgrade
  2015-06-16 19:32:44.080 | 

  2015-06-16 19:32:44.080 | 
  2015-06-16 19:32:44.080 | Captured traceback:
  2015-06-16 19:32:44.081 | ~~~
  2015-06-16 19:32:44.081 | Traceback (most recent call last):
  2015-06-16 19:32:44.081 |   File 
keystone/tests/unit/test_sql_upgrade.py, line 196, in tearDown
  2015-06-16 19:32:44.081 | conn.execute(schema.DropConstraint(fkc))
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 914, in execute
  2015-06-16 19:32:44.081 | return meth(self, multiparams, params)
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/ddl.py,
 line 68, in _execute_on_connection
  2015-06-16 19:32:44.081 | return connection._execute_ddl(self, 
multiparams, params)
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 968, in _execute_ddl
  2015-06-16 19:32:44.081 | compiled
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1146, in _execute_context
  2015-06-16 19:32:44.082 | context)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1337, in _handle_dbapi_exception
  2015-06-16 19:32:44.082 | util.raise_from_cause(newraise, exc_info)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py,
 line 199, in raise_from_cause
  2015-06-16 19:32:44.082 | reraise(type(exception), exception, 
tb=exc_tb)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1139, in _execute_context
  2015-06-16 19:32:44.082 | context)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py,
 line 450, in do_execute
  2015-06-16 19:32:44.082 | cursor.execute(statement, parameters)
  2015-06-16 19:32:44.082 | sqlalchemy.exc.OperationalError: 
(sqlite3.OperationalError) near DROP: syntax error [SQL: u'ALTER TABLE 
group DROP CONSTRAINT fk_group_domain_id']

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1467008/+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 1467008] Re: Unit tests fail with sqlalchemy 1.1.0

[Brant Knudson]

** Also affects: glance
   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/1467008

Title:
  Unit tests fail with sqlalchemy 1.1.0

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  Unit tests fail with sqlalchemy 1.1.0. See 
https://review.openstack.org/#/c/190405/ , which tries to upgrade the 
requirement and fails.

  2015-06-16 19:32:44.080 | 
keystone.tests.unit.test_sql_upgrade.SqlUpgradeTests.test_region_url_upgrade
  2015-06-16 19:32:44.080 | 

  2015-06-16 19:32:44.080 | 
  2015-06-16 19:32:44.080 | Captured traceback:
  2015-06-16 19:32:44.081 | ~~~
  2015-06-16 19:32:44.081 | Traceback (most recent call last):
  2015-06-16 19:32:44.081 |   File 
keystone/tests/unit/test_sql_upgrade.py, line 196, in tearDown
  2015-06-16 19:32:44.081 | conn.execute(schema.DropConstraint(fkc))
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 914, in execute
  2015-06-16 19:32:44.081 | return meth(self, multiparams, params)
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/ddl.py,
 line 68, in _execute_on_connection
  2015-06-16 19:32:44.081 | return connection._execute_ddl(self, 
multiparams, params)
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 968, in _execute_ddl
  2015-06-16 19:32:44.081 | compiled
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1146, in _execute_context
  2015-06-16 19:32:44.082 | context)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1337, in _handle_dbapi_exception
  2015-06-16 19:32:44.082 | util.raise_from_cause(newraise, exc_info)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py,
 line 199, in raise_from_cause
  2015-06-16 19:32:44.082 | reraise(type(exception), exception, 
tb=exc_tb)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1139, in _execute_context
  2015-06-16 19:32:44.082 | context)
  2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py,
 line 450, in do_execute
  2015-06-16 19:32:44.082 | cursor.execute(statement, parameters)
  2015-06-16 19:32:44.082 | sqlalchemy.exc.OperationalError: 
(sqlite3.OperationalError) near DROP: syntax error [SQL: u'ALTER TABLE 
group DROP CONSTRAINT fk_group_domain_id']

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1467008/+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 1467008] [NEW] Unit tests fail with sqlalchemy 1.1.0

[Brant Knudson]

Public bug reported:


Unit tests fail with sqlalchemy 1.1.0. See 
https://review.openstack.org/#/c/190405/ , which tries to upgrade the 
requirement and fails.

2015-06-16 19:32:44.080 | 
keystone.tests.unit.test_sql_upgrade.SqlUpgradeTests.test_region_url_upgrade
2015-06-16 19:32:44.080 | 

2015-06-16 19:32:44.080 | 
2015-06-16 19:32:44.080 | Captured traceback:
2015-06-16 19:32:44.081 | ~~~
2015-06-16 19:32:44.081 | Traceback (most recent call last):
2015-06-16 19:32:44.081 |   File keystone/tests/unit/test_sql_upgrade.py, 
line 196, in tearDown
2015-06-16 19:32:44.081 | conn.execute(schema.DropConstraint(fkc))
2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 914, in execute
2015-06-16 19:32:44.081 | return meth(self, multiparams, params)
2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/ddl.py,
 line 68, in _execute_on_connection
2015-06-16 19:32:44.081 | return connection._execute_ddl(self, 
multiparams, params)
2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 968, in _execute_ddl
2015-06-16 19:32:44.081 | compiled
2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1146, in _execute_context
2015-06-16 19:32:44.082 | context)
2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1337, in _handle_dbapi_exception
2015-06-16 19:32:44.082 | util.raise_from_cause(newraise, exc_info)
2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py,
 line 199, in raise_from_cause
2015-06-16 19:32:44.082 | reraise(type(exception), exception, tb=exc_tb)
2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 1139, in _execute_context
2015-06-16 19:32:44.082 | context)
2015-06-16 19:32:44.082 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py,
 line 450, in do_execute
2015-06-16 19:32:44.082 | cursor.execute(statement, parameters)
2015-06-16 19:32:44.082 | sqlalchemy.exc.OperationalError: 
(sqlite3.OperationalError) near DROP: syntax error [SQL: u'ALTER TABLE 
group DROP CONSTRAINT fk_group_domain_id']

** Affects: keystone
 Importance: High
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: keystone
   Importance: Undecided = High

** Changed in: keystone
   Status: New = 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/1467008

Title:
  Unit tests fail with sqlalchemy 1.1.0

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  Unit tests fail with sqlalchemy 1.1.0. See 
https://review.openstack.org/#/c/190405/ , which tries to upgrade the 
requirement and fails.

  2015-06-16 19:32:44.080 | 
keystone.tests.unit.test_sql_upgrade.SqlUpgradeTests.test_region_url_upgrade
  2015-06-16 19:32:44.080 | 

  2015-06-16 19:32:44.080 | 
  2015-06-16 19:32:44.080 | Captured traceback:
  2015-06-16 19:32:44.081 | ~~~
  2015-06-16 19:32:44.081 | Traceback (most recent call last):
  2015-06-16 19:32:44.081 |   File 
keystone/tests/unit/test_sql_upgrade.py, line 196, in tearDown
  2015-06-16 19:32:44.081 | conn.execute(schema.DropConstraint(fkc))
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 914, in execute
  2015-06-16 19:32:44.081 | return meth(self, multiparams, params)
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/ddl.py,
 line 68, in _execute_on_connection
  2015-06-16 19:32:44.081 | return connection._execute_ddl(self, 
multiparams, params)
  2015-06-16 19:32:44.081 |   File 
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py,
 line 968, in _execute_ddl
  2015-06-16 19:32:44.081

[Yahoo-eng-team] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled

[Brant Knudson]

Was able to recreate locally on master.

** Changed in: keystone
   Status: Won't Fix = Confirmed

** Changed in: keystone
   Importance: Undecided = Medium

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1465922

Title:
  Password visible in clear text in keystone.log when user created and
  keystone debug logging is enabled

Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  grep CLEARTEXTPASSWORD keystone.log

  2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-]
  RBAC: Authorizing identity:create_user(user={u'domain_id': u'default',
  u'password': u'CLEARTEXTPASSWORD', u'enabled': True,
  u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name':
  u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site-
  packages/keystone/common/controller.py:57

  Issue code:
  
https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57

  LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {
  'action': action,
  'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])})

  Shadow the values of sensitive fields like 'password' by some
  meaningless garbled text like X is one way to fix.

  Well, in addition to this, I think we should never pass the 'password'
  with its original value along the code and save it in any persistence,
  instead we should convert it to a strong hash value as early as
  possible. With the help of a good hash system, we never have to need
  the original value of the password, right?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1465922/+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 1464366] [NEW] unit tests fail based on wall clock time

[Brant Knudson]

Public bug reported:


We've got a lot of tests that depend on how long the test takes to run. Tests 
can take a long time just because you have a slow or overloaded system, or 
maybe you're trying to step through it with the debugger.

The tests that fail generally don't care about the time and aren't
attempting to verify performance, but still require that the test run
quickly enough.

Tests shouldn't depend on the wall clock time, just like they shouldn't
depend on any external factors.

Here's an example of a failing test:

keystone.tests.unit.test_auth.AuthWithRemoteUser.test_scoped_remote_authn
-

Captured traceback:
~~~
Traceback (most recent call last):
  File keystone/tests/unit/test_auth.py, line 741, in 
test_scoped_remote_authn
enforce_audit_ids=False)
  File keystone/tests/unit/test_auth.py, line 104, in assertEqualTokens
timeutils.parse_isotime(b['access']['token']['expires']))
  File keystone/tests/unit/core.py, line 521, in 
assertCloseEnoughForGovernmentWork
self.assertTrue(abs(a - b).seconds = delta, msg)
  File 
/home/jenkins/workspace/keystone/.tox/py27/local/lib/python2.7/site-packages/unittest2/case.py,
 line 678, in assertTrue
raise self.failureException(msg)
AssertionError: False is not true : 2015-06-11 13:34:46+00:00 != 2015-06-11 
13:34:50+00:00 within 3 delta

It took 4 seconds rather than 3.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1464366

Title:
  unit tests fail based on wall clock time

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  We've got a lot of tests that depend on how long the test takes to run. Tests 
can take a long time just because you have a slow or overloaded system, or 
maybe you're trying to step through it with the debugger.

  The tests that fail generally don't care about the time and aren't
  attempting to verify performance, but still require that the test run
  quickly enough.

  Tests shouldn't depend on the wall clock time, just like they
  shouldn't depend on any external factors.

  Here's an example of a failing test:

  keystone.tests.unit.test_auth.AuthWithRemoteUser.test_scoped_remote_authn
  -

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File keystone/tests/unit/test_auth.py, line 741, in 
test_scoped_remote_authn
  enforce_audit_ids=False)
File keystone/tests/unit/test_auth.py, line 104, in assertEqualTokens
  timeutils.parse_isotime(b['access']['token']['expires']))
File keystone/tests/unit/core.py, line 521, in 
assertCloseEnoughForGovernmentWork
  self.assertTrue(abs(a - b).seconds = delta, msg)
File 
/home/jenkins/workspace/keystone/.tox/py27/local/lib/python2.7/site-packages/unittest2/case.py,
 line 678, in assertTrue
  raise self.failureException(msg)
  AssertionError: False is not true : 2015-06-11 13:34:46+00:00 != 
2015-06-11 13:34:50+00:00 within 3 delta

  It took 4 seconds rather than 3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1464366/+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 1461251] Re: Stop using deprecated oslo_utils.timeutils.isotime

[Brant Knudson]

** Also affects: python-keystoneclient
   Importance: Undecided
   Status: New

** Changed in: python-keystoneclient
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1461251

Title:
  Stop using deprecated oslo_utils.timeutils.isotime

Status in OpenStack Identity (Keystone):
  Fix Committed
Status in Oslo utility library:
  New
Status in Python client library for Keystone:
  In Progress

Bug description:
  oslo_utils.timeutils.isotime() is deprecated as of 1.6 so we need to
  stop using it.

  This breaks unit tests in keystone since we've got a check for calling
  deprecated functions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1461251/+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 1461251] [NEW] Stop using deprecated oslo_utils.timeutils.isotime

[Brant Knudson]

Public bug reported:

oslo_utils.timeutils.isotime() is deprecated as of 1.6 so we need to
stop using it.

This breaks unit tests in keystone since we've got a check for calling
deprecated functions.

** Affects: keystone
 Importance: Critical
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: keystone
   Importance: Undecided = Critical

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1461251

Title:
  Stop using deprecated oslo_utils.timeutils.isotime

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  oslo_utils.timeutils.isotime() is deprecated as of 1.6 so we need to
  stop using it.

  This breaks unit tests in keystone since we've got a check for calling
  deprecated functions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1461251/+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 1449260] Re: Sanitation of metadata label

[Brant Knudson]

** Changed in: horizon
   Status: Fix Released = Fix Committed

** Tags added: icehouse-backport-potential juno-backport-potential kilo-
backport-potential

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

Title:
  Sanitation of metadata label

Status in OpenStack Dashboard (Horizon):
  Fix Committed
Status in OpenStack Security Advisories:
  Triaged

Bug description:
  1) Start up Horizon
  2) Go to Images
  3) Next to an image, pick Update Metadata
  4) From the dropdown button, select Update Metadata
  5) In the Custom box, enter a value with some HTML like 
'/scriptscriptalert(1)/script//', click +
  6) On the right-hand side, give it a value, like ee
  7) Click Save
  8) Pick Update Metadata for the image again, the page will fail to load, 
and the JavaScript console says:

  SyntaxError: invalid property id
  var existing_metadata = {

  An alternative is if you change the URL to update_metadata for the
  image (for example,
  
http://192.168.122.239/admin/images/fa62ba27-e731-4ab9-8487-f31bac355b4c/update_metadata/),
  it will actually display the alert box and a bunch of junk.

  I'm not sure if update_metadata is actually a page, though... can't
  figure out how to get to it other than typing it in.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1449260/+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 1449850] Re: Join multiple criteria together

[Brant Knudson]

** Changed in: keystone
   Status: In Progress = Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1449850

Title:
  Join multiple criteria together

Status in OpenStack Identity (Keystone):
  Opinion

Bug description:
  SQLAlchemy supports to join multiple criteria together, this is
  provided to build the query statements when there is multiple
  filtering criterion instead of constructing query statement one by
  one,  just *assume* SQLAlchemy prefer to use it in this way, and the
  code looks more clean after refactoring.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1449850/+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 1346778] Re: Neutron does not work by default without a keystone admin user

[Brant Knudson]

There appears to be a similar issue for ceilometer -- it needs admin
role when it should not.

** Also affects: ceilometer
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1346778

Title:
  Neutron does not work by default without a keystone admin user

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  The default neutron policy.json 'context_is_admin' only matches on
  'role:admin' and the account that neutron is configured with must
  match 'context_is_admin' for neutron to function correctly. This means
  that without modifying policy.json, a deployer cannot use a non-admin
  account for neutron.

  The policy.json keywords have no way to match the username of the
  neutron keystone credentials. This means that policy.json has to be
  modified for every deployment that doesn't use an admin user to match
  the keystone user neutron is configured with.

  This seems like an unnecessary burden to leave to deployers to achieve
  a secure deployment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1346778/+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 1445199] Re: Nova user should not have admin role

[Brant Knudson]

I think the reason the 'nova' user needs the 'admin' role is because
neutron uses it to send a network allocation event back to nova. Nova
should be configured by default to allow users with the 'service' role
to do this operation and not require the 'admin' role.

** Information type changed from Public to Public Security

** Also affects: nova
   Importance: Undecided
   Status: New

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

Title:
  Nova user should not have admin role

Status in devstack - openstack dev environments:
  New
Status in OpenStack Compute (Nova):
  New

Bug description:
  
  Most of the service users are granted the 'service' role on the 'service' 
project, except the 'nova' user which is given 'admin'. The 'nova' user should 
also be given only the 'service' role on the 'service' project.

  This is for security hardening.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1445199/+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 1441300] [NEW] keystone-manage man page updates

[Brant Knudson]

Public bug reported:


The keystone-manage man page doesn't show any of the new fernet commands, so 
it's out of date.

** Affects: keystone
 Importance: Medium
 Status: Confirmed


** 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/1441300

Title:
  keystone-manage man page updates

Status in OpenStack Identity (Keystone):
  Confirmed

Bug description:
  
  The keystone-manage man page doesn't show any of the new fernet commands, so 
it's out of date.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1441300/+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 1441393] [NEW] keystone unit tests fail with pymongo 3.0

[Brant Knudson]

Public bug reported:


pymongo 3.0 was released 2015-04-07. This causes keystone tests to fail:

Traceback (most recent call last):
  File keystone/tests/unit/test_cache_backend_mongo.py, line 357, in 
test_correct_read_preference
region.set(random_key, dummyValue10)  
   
...
  File keystone/common/cache/backends/mongo.py, line 363, in 
get_cache_collection 
self.read_preference = pymongo.read_preferences.mongos_enum(

AttributeError: 'module' object has no attribute 'mongos_enum'  


Traceback (most recent call last):
  File keystone/tests/unit/test_cache_backend_mongo.py, line 345, in 
test_incorrect_read_preference
random_key, dummyValue10) 
 
...
  File keystone/common/cache/backends/mongo.py, line 168, in client   
  
self.api.get_cache_collection() 
  
  File keystone/common/cache/backends/mongo.py, line 363, in 
get_cache_collection   
self.read_preference = pymongo.read_preferences.mongos_enum(
  
AttributeError: 'module' object has no attribute 'mongos_enum'

** 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/1441393

Title:
  keystone unit tests fail with pymongo 3.0

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  pymongo 3.0 was released 2015-04-07. This causes keystone tests to fail:

  Traceback (most recent call last):
File keystone/tests/unit/test_cache_backend_mongo.py, line 357, in 
test_correct_read_preference
  region.set(random_key, dummyValue10)
 
  ...
File keystone/common/cache/backends/mongo.py, line 363, in 
get_cache_collection 
  self.read_preference = pymongo.read_preferences.mongos_enum(  
  
  AttributeError: 'module' object has no attribute 'mongos_enum'
  

  Traceback (most recent call last):
File keystone/tests/unit/test_cache_backend_mongo.py, line 345, in 
test_incorrect_read_preference
  random_key, dummyValue10)   
   
  ...
File keystone/common/cache/backends/mongo.py, line 168, in client 

  self.api.get_cache_collection()   

File keystone/common/cache/backends/mongo.py, line 363, in 
get_cache_collection   
  self.read_preference = pymongo.read_preferences.mongos_enum(  

  AttributeError: 'module' object has no attribute 'mongos_enum'

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1441393/+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 1440123] [NEW] keystone-manage fails if optional fernet packages not installed

[Brant Knudson]

Public bug reported:


If I'm not using fernet, so don't install the packages that are only required 
if fernet is used (e.g., cryptography), then all keystone-manage commands will 
fail to run with an exception due to the missing package.

keystone-manage commands that aren't fernet-related should work when the
non-fernet packages are not installed.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1440123

Title:
  keystone-manage fails if optional fernet packages not installed

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  If I'm not using fernet, so don't install the packages that are only required 
if fernet is used (e.g., cryptography), then all keystone-manage commands will 
fail to run with an exception due to the missing package.

  keystone-manage commands that aren't fernet-related should work when
  the non-fernet packages are not installed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1440123/+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 1434103] Re: SQL schema downgrades are no longer supported

[Brant Knudson]

** Also affects: keystone
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1434103

Title:
  SQL schema downgrades are no longer supported

Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Neutron (virtual network service):
  Fix Committed
Status in OpenStack Data Processing (Sahara):
  In Progress

Bug description:
  Approved cross-project spec: https://review.openstack.org/152337

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1434103/+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 1435396] [NEW] No notifications for role grants using v2

[Brant Knudson]

Public bug reported:


If you use the v3 API to add or remove role grants, you get notifications that 
it happened, but if you use the v2.0 API, you don't get notifications.

Keystone needs to send notifications when the v2 API is used, also.

For example, start with devstack, then grant a role:

$ keystone user-role-add --user demo --tenant admin --role admin
   - gets a notification for identity.authenticate, but none for 
identity.created.role_assignment

Same for revoke:

$ keystone user-role-remove --user demo --tenant admin --role admin
   - gets a notification for identity.authenticate, but none for 
identity.deleted.role_assignment

v3 works fine:

$ curl -X PUT -H X-Auth-Token: $TOKEN
http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

$ curl -X DELETE -H X-Auth-Token: $TOKEN
http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1435396

Title:
  No notifications for role grants using v2

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  If you use the v3 API to add or remove role grants, you get notifications 
that it happened, but if you use the v2.0 API, you don't get notifications.

  Keystone needs to send notifications when the v2 API is used, also.

  For example, start with devstack, then grant a role:

  $ keystone user-role-add --user demo --tenant admin --role admin
 - gets a notification for identity.authenticate, but none for 
identity.created.role_assignment

  Same for revoke:

  $ keystone user-role-remove --user demo --tenant admin --role admin
 - gets a notification for identity.authenticate, but none for 
identity.deleted.role_assignment

  v3 works fine:

  $ curl -X PUT -H X-Auth-Token: $TOKEN
  http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

  $ curl -X DELETE -H X-Auth-Token: $TOKEN
  http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1435396/+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 1432191] [NEW] Logs useless debugging issue with external auth

[Brant Knudson]

Public bug reported:


I was trying to figure out why a system was failing to authenticate using some 
authentication middleware. Using the debugger I was able to figure out that 
there was no 'external' auth plugin registered (the admin was trying to figure 
it out themselves and had made several mistakes). This would have been easy to 
figure out if only the logs had mentioned that there wasn't an 'external' auth 
plugin registered.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1432191

Title:
  Logs useless debugging issue with external auth

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  I was trying to figure out why a system was failing to authenticate using 
some authentication middleware. Using the debugger I was able to figure out 
that there was no 'external' auth plugin registered (the admin was trying to 
figure it out themselves and had made several mistakes). This would have been 
easy to figure out if only the logs had mentioned that there wasn't an 
'external' auth plugin registered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1432191/+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 1431088] [NEW] eventlet_server options reporting as deprecated

[Brant Knudson]

Public bug reported:


Some of the options that were moved to the eventlet_server section in the 
config file are reporting as deprecated.

2015-03-11 19:43:40.450 WARNING oslo_config.cfg [-] Option admin_workers from 
group eventlet_server is deprecated. Use option admin_workers from group 
eventlet_server.
2015-03-11 19:43:40.450 WARNING oslo_config.cfg [-] Option public_workers 
from group eventlet_server is deprecated. Use option public_workers from 
group eventlet_server.

The options in the DEFAULT section were deprecated.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1431088

Title:
  eventlet_server options reporting as deprecated

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  Some of the options that were moved to the eventlet_server section in the 
config file are reporting as deprecated.

  2015-03-11 19:43:40.450 WARNING oslo_config.cfg [-] Option admin_workers 
from group eventlet_server is deprecated. Use option admin_workers from 
group eventlet_server.
  2015-03-11 19:43:40.450 WARNING oslo_config.cfg [-] Option public_workers 
from group eventlet_server is deprecated. Use option public_workers from 
group eventlet_server.

  The options in the DEFAULT section were deprecated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1431088/+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 1430515] [NEW] fernet tokens tests using pending deprecation methods

[Brant Knudson]

Public bug reported:

When running unit tests, a bunch of pending deprecation warnings are
logged. Here's an example:

 /opt/stack/keystone/.tox/py27/local/lib/python2.7/site-
packages/cryptography/hazmat/backends/openssl/dsa.py:177:
PendingDeprecationWarning: The DSAPublicKeyWithNumbers interface has
been renamed to DSAPublicKeyWithSerialization

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: fernet

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1430515

Title:
  fernet tokens tests using pending deprecation methods

Status in OpenStack Identity (Keystone):
  New

Bug description:
  When running unit tests, a bunch of pending deprecation warnings are
  logged. Here's an example:

   /opt/stack/keystone/.tox/py27/local/lib/python2.7/site-
  packages/cryptography/hazmat/backends/openssl/dsa.py:177:
  PendingDeprecationWarning: The DSAPublicKeyWithNumbers interface has
  been renamed to DSAPublicKeyWithSerialization

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1430515/+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 1429663] [NEW] local tests failing in test_time_string_to_int_conversions

[Brant Knudson]

self.assertEqual(expected_time_str, actual_time_str)

  File 
/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 348, in assertEqual
self.assertThat(observed, matcher, message) 

  File 
/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 433, in assertThat 
raise mismatch_error
MismatchError: '2015-03-08T22:13:49Z' != '2015-03-08T23:13:49Z'

It's off by an hour for some reason.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1429663

Title:
  local tests failing in test_time_string_to_int_conversions

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  When running local tests with tox -e py27, one of the tests is failing:

  
keystone.tests.unit.token.test_fernet_provider.TestBaseTokenFormatter.test_time_string_to_int_conversions
  
-

  Captured traceback:
  ~~~
  Traceback (most recent call last):
  _StringException: Empty attachments:
pythonlogging:''-1
stderr
stdout
  
  pythonlogging:'': {{{   
  Adding cache-proxy 'keystone.tests.unit.test_cache.CacheIsolatingProxy' 
to backend.
  Created a new key: /tmp/tmpDxjwUU/tmpUgUvin/0 
 
  Starting key rotation with 1 key files: ['/tmp/tmpDxjwUU/tmpUgUvin/0']
 
  Current primary key is: 0 
 
  Next primary key will be: 1   
 
  Promoted key 0 to be the primary: 1   
 
  Created a new key: /tmp/tmpDxjwUU/tmpUgUvin/0 
 
  Excess keys to purge: []  
 
  }}}   
 

 
  Traceback (most recent call last):
 
File keystone/tests/unit/token/test_fernet_provider.py, line 105, in 
test_time_string_to_int_conversions
  self.assertEqual(expected_time_str, actual_time_str)  
  
File 
/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 348, in assertEqual
  self.assertThat(observed, matcher, message)   
  
File 
/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 433, in assertThat 
  raise mismatch_error  
  
  MismatchError: '2015-03-08T22:13:49Z' != '2015-03-08T23:13:49Z'   
  

  
  Traceback (most recent call last):
  
  _StringException: Empty attachments:  
  
pythonlogging:''-1  
  
stderr  
  
stdout  
  

  
  pythonlogging:'': {{{ 
  
  Adding cache-proxy 'keystone.tests.unit.test_cache.CacheIsolatingProxy' 
to backend. 
  Created a new key: /tmp/tmpDxjwUU/tmpUgUvin/0 
  
  Starting key rotation with 1 key files: ['/tmp/tmpDxjwUU/tmpUgUvin/0']
  
  Current primary key is: 0

[Yahoo-eng-team] [Bug 1408423] Re: Requirements are out of date

[Brant Knudson]

I think these fixes were released some time ago.

** Changed in: keystone
   Status: In Progress = Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1408423

Title:
  Requirements are out of date

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  There have been several removals of code due to

  1) switching to oslo libraries from oslo-incubator
  2) not testing old versions of python-keystoneclient
  3) deprecations getting removed, etc.

  Along with these changes, one should look through requirements.txt and
  test-requirements.txt to see if the requirements are still used, but
  it looks like this hasn't happened so now we've got a bunch of things
  in *requirements.txt which should be removed.

  Having extra requirements listed makes it so that downstream packagers
  might have extra unnecessary requirements on their packages. Also, if
  the requirement isn't used by keystone or any of the other
  dependencies then it won't need to be installed in the tox venv and
  make testing faster.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1408423/+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 1424061] Re: keystone server should default to localhost-only

[Brant Knudson]

** Changed in: keystone
   Status: In Progress = Won't Fix

** Changed in: keystone
 Assignee: Brant Knudson (blk-u) = (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1424061

Title:
  keystone server should default to localhost-only

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Identity (Keystone):
  Won't Fix

Bug description:
  
  By default keystone will listen on all interfaces. Keystone should use secure 
defaults. In this case, listen on localhost-only by default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1424061/+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 1424496] [NEW] Documentation lacking for mapping of operation policy target

[Brant Knudson]

Public bug reported:


There's no documentation that says what the mapping is of target in the 
policy.json file to the operation.

For example, the policy.json has a target for identity:get_region.
This is the rule for the operation of GET /v3/regions/{region_id} . But
there's no way to tell this without reading the code because there's no
documentation for it.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1424496

Title:
  Documentation lacking for mapping of operation policy target

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  There's no documentation that says what the mapping is of target in the 
policy.json file to the operation.

  For example, the policy.json has a target for identity:get_region.
  This is the rule for the operation of GET /v3/regions/{region_id} .
  But there's no way to tell this without reading the code because
  there's no documentation for it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1424496/+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 1424089] [NEW] Use SystemRandom rather than random

[Brant Knudson]

*** This bug is a security vulnerability ***

Public security bug reported:


SystemRandom should be preferred over direct use of random.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1424089

Title:
  Use SystemRandom rather than random

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  SystemRandom should be preferred over direct use of random.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1424089/+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 1424061] [NEW] keystone server should default to localhost-only

[Brant Knudson]

*** This bug is a security vulnerability ***

Public security bug reported:


By default keystone will listen on all interfaces. Keystone should use secure 
defaults. In this case, listen on localhost-only by default.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1424061

Title:
  keystone server should default to localhost-only

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  By default keystone will listen on all interfaces. Keystone should use secure 
defaults. In this case, listen on localhost-only by default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1424061/+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 1421966] [NEW] Getting role for trust is double-protected

[Brant Knudson]

Public bug reported:


The function for getting or checking a role for trust (GET/HEAD 
/v3/OS-TRUST/trusts/{trust_id}/roles/{role_id}) winds up being protected first 
by `get_role_for_trust` and then by `check_role_for_trust`. This is because 
get_role_for_trust winds up calling self.check_role_for_trust()[1]. There's 
actually no external route for check_role_for_trust, so this policy target 
should be removed.

[1]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n272

** 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/1421966

Title:
  Getting role for trust is double-protected

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  The function for getting or checking a role for trust (GET/HEAD 
/v3/OS-TRUST/trusts/{trust_id}/roles/{role_id}) winds up being protected first 
by `get_role_for_trust` and then by `check_role_for_trust`. This is because 
get_role_for_trust winds up calling self.check_role_for_trust()[1]. There's 
actually no external route for check_role_for_trust, so this policy target 
should be removed.

  [1]
  
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/controllers.py#n272

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1421966/+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 1421968] [NEW] List Endpoint Groups Associated with project not routed

[Brant Knudson]

Public bug reported:


I was looking through the sample policy.json file and noticed that the 
identity:list_endpoint_groups_for_project target doesn't have a corresponding 
mapping in the routers[1]. Looks like there's supposed to be a router mapping 
/v3/OS-EP-FILTER/endpoint_groups/projects/{project_id}[2] to 
list_endpoint_groups_for_project. Since there's no mapping for the path, the 
keystone server is just going to 404.

[1] This would be in 
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/endpoint_filter/routers.py
[2] 
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-ep-filter-ext.html#list-endpoint-groups-associated-with-project

** 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/1421968

Title:
  List Endpoint Groups Associated with project not routed

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  I was looking through the sample policy.json file and noticed that the 
identity:list_endpoint_groups_for_project target doesn't have a corresponding 
mapping in the routers[1]. Looks like there's supposed to be a router mapping 
/v3/OS-EP-FILTER/endpoint_groups/projects/{project_id}[2] to 
list_endpoint_groups_for_project. Since there's no mapping for the path, the 
keystone server is just going to 404.

  [1] This would be in 
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/endpoint_filter/routers.py
  [2] 
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-ep-filter-ext.html#list-endpoint-groups-associated-with-project

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1421968/+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 1421971] [NEW] get_endpoint_group_in_project missing from sample policy files

[Brant Knudson]

Public bug reported:

We've got an mapping for get_endpoint_group_in_project, which maps to
GET /v3/OS-EP-
FILTER/endpoint_groups/{endpoint_group_id}/projects/{project_id}, but
it's not a target in the sample policy files. All the operations should
be in the sample policy file so admins know what's available.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1421971

Title:
  get_endpoint_group_in_project missing from sample policy files

Status in OpenStack Identity (Keystone):
  New

Bug description:
  We've got an mapping for get_endpoint_group_in_project, which maps
  to GET /v3/OS-EP-
  FILTER/endpoint_groups/{endpoint_group_id}/projects/{project_id}, but
  it's not a target in the sample policy files. All the operations
  should be in the sample policy file so admins know what's available.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1421971/+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 1421825] [NEW] Sample policy should allow user to validate and revoke own token

[Brant Knudson]

Public bug reported:

The sample policy doesn't allow a non-admin user to validate or revoke
their own token.

Steps to recreate:

0) Start with devstack
1) Get a token for a non-admin user

$ curl -i   -H Content-Type: application/json   -d '
{ auth: {
identity: {
  methods: [password],
  password: {
user: {
  name: demo,
  domain: { id: default },
  password: demopwd
}
  }
},
scope: {
  project: {
name: demo,
domain: { id: default }
  }
}
  }
}'   http://localhost:35357/v3/auth/tokens ; echo

$ TOKEN=e91bab6a52e44e39ba7ca63b04bb717b


2) Try to get the token using the token using v3:

$ curl -H X-Auth-Token: $TOKEN -H X-Subject-Token: $TOKEN 
http://localhost:35357/v3/auth/tokens
{error: {message: You are not authorized to perform the requested action: 
identity:validate_token (Disable debug mode to suppress these details.), 
code: 403, title: Forbidden}}


3) Try to validate the token using the token using v3:

$ curl -I -H X-Auth-Token: $TOKEN -H X-Subject-Token: $TOKEN 
http://localhost:35357/v3/auth/tokens
HTTP/1.1 403 Forbidden
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 185
Date: Fri, 13 Feb 2015 20:00:21 GMT


3) Try to get the token using the token using v2:

$ curl -H X-Auth-Token: $TOKEN http://localhost:35357/v2.0/tokens/$TOKEN
{error: {message: You are not authorized to perform the requested action: 
identity:validate_token (Disable debug mode to suppress these details.), 
code: 403, title: Forbidden}}


4) Try to validate the token using the token using v2:

$ curl -I -H X-Auth-Token: $TOKEN http://localhost:35357/v2.0/tokens/$TOKEN
HTTP/1.1 403 Forbidden
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 193
Date: Fri, 13 Feb 2015 20:11:49 GMT


5) Try to revoke the token using the token using v3:

$ curl -X DELETE -H X-Auth-Token: $TOKEN -H X-Subject-Token: $TOKEN 
http://localhost:35357/v3/auth/tokens
{error: {message: You are not authorized to perform the requested action: 
identity:revoke_token (Disable debug mode to suppress these details.), code: 
403, title: Forbidden}


6) Try to revoke the token using the token using v2:

$ curl -X DELETE -H X-Auth-Token: $TOKEN 
http://localhost:35357/v2.0/tokens/$TOKEN
{error: {message: You are not authorized to perform the requested action: 
admin_required (Disable debug mode to suppress these details.), code: 403, 
title: Forbidden}}

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1421825

Title:
  Sample policy should allow user to validate and revoke own token

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The sample policy doesn't allow a non-admin user to validate or revoke
  their own token.

  Steps to recreate:

  0) Start with devstack
  1) Get a token for a non-admin user

  $ curl -i   -H Content-Type: application/json   -d '
  { auth: {
  identity: {
methods: [password],
password: {
  user: {
name: demo,
domain: { id: default },
password: demopwd
  }
}
  },
  scope: {
project: {
  name: demo,
  domain: { id: default }
}
  }
}
  }'   http://localhost:35357/v3/auth/tokens ; echo

  $ TOKEN=e91bab6a52e44e39ba7ca63b04bb717b

  
  2) Try to get the token using the token using v3:

  $ curl -H X-Auth-Token: $TOKEN -H X-Subject-Token: $TOKEN 
http://localhost:35357/v3/auth/tokens
  {error: {message: You are not authorized to perform the requested 
action: identity:validate_token (Disable debug mode to suppress these 
details.), code: 403, title: Forbidden}}

  
  3) Try to validate the token using the token using v3:

  $ curl -I -H X-Auth-Token: $TOKEN -H X-Subject-Token: $TOKEN 
http://localhost:35357/v3/auth/tokens
  HTTP/1.1 403 Forbidden
  Vary: X-Auth-Token
  Content-Type: application/json
  Content-Length: 185
  Date: Fri, 13 Feb 2015 20:00:21 GMT

  
  3) Try to get the token using the token using v2:

  $ curl -H X-Auth-Token: $TOKEN http://localhost:35357/v2.0/tokens/$TOKEN
  {error: {message: You are not authorized to perform the requested 
action: identity:validate_token (Disable debug mode to suppress these 
details.), code: 403, title: Forbidden}}

  
  4) Try to validate the token using the token using v2:

  $ curl -I -H X-Auth-Token: $TOKEN http://localhost:35357/v2.0/tokens/$TOKEN
  HTTP/1.1 403 Forbidden
  Vary: X-Auth-Token
  Content-Type: application/json
  Content-Length: 193
  Date: Fri, 13 Feb 2015 20:11:49 GMT

  
  5) Try to revoke the token using the token using v3:

  $ curl -X DELETE -H X-Auth-Token: $TOKEN -H X-Subject-Token: $TOKEN 
http

[Yahoo-eng-team] [Bug 1420863] [NEW] Default setting should be secure

[Brant Knudson]

Public bug reported:


Horizon has some instructions for setting it up in a secure way[1]. These 
settings should be the default.

[1] http://docs.openstack.org/developer/horizon/topics/deployment.html
#secure-site-recommendations

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: security

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

Title:
  Default setting should be secure

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  
  Horizon has some instructions for setting it up in a secure way[1]. These 
settings should be the default.

  [1] http://docs.openstack.org/developer/horizon/topics/deployment.html
  #secure-site-recommendations

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1420863/+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 1401664] Re: Update role using LDAP backend requires name

[Brant Knudson]

This was fixed in master with https://review.openstack.org/#/c/141186/
and juno with https://review.openstack.org/#/c/142552/ . I put the wrong
bug in the commit message.

** Changed in: keystone
   Status: New = Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1401664

Title:
  Update role using LDAP backend requires name

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  
  When updating a role and the keystone identity server is configured to use 
LDAP as the backend, you get a 500 error if the update doesn't have the name. 
For example, if you just disable a role, it fails with a 500 error.

  0. Start with devstack configured to use LDAP assignment backend.

  1. Get a token:

  $ curl -i \
-H Content-Type: application/json \
-d '
  { auth: {
  identity: {
methods: [password],
password: {
  user: {
name: admin,
domain: { id: default },
password: adminpwd
  }
}
  },
  scope: {
project: {
  name: demo,
  domain: { id: default }
}
  }
}
  }' \
http://localhost:35357/v3/auth/tokens ; echo

  $ TOKEN=...

  2. Pick a role.

  $ curl \
  -H X-Auth-Token: $TOKEN \
  http://localhost:35357/v3/roles | python -m json.tool

  $ ROLE_ID=36a9eede308d41e8a92effce2e46cc4a

  3. Update without a name.

  $ curl -X PATCH \
  -H X-Auth-Token: $TOKEN \
  -H Content-Type: application/json \
  -d '{role: {enabled: false}}' \
  http://localhost:35357/v3/roles/$ROLE_ID

  {error: {message: An unexpected error prevented the server from
  fulfilling your request: 'name' (Disable debug mode to suppress these
  details.), code: 500, title: Internal Server Error}}

  
  The update operation should be successful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1401664/+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 1408658] [NEW] migration 61 downgrade fails using mysql

[Brant Knudson]

Public bug reported:


When trying to downgrade from version 61, it fails with an AttributeError.

$ keystone-manage db_sync 60
2015-01-08 08:29:56.494 CRITICAL keystone [-] AttributeError: 'MetaData' object 
has no attribute 'c'

2015-01-08 08:29:56.494 TRACE keystone Traceback (most recent call last):
2015-01-08 08:29:56.494 TRACE keystone   File /usr/local/bin/keystone-manage, 
line 6, in module
2015-01-08 08:29:56.494 TRACE keystone exec(compile(open(__file__).read(), 
__file__, 'exec'))
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
2015-01-08 08:29:56.494 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 311, in main
2015-01-08 08:29:56.494 TRACE keystone CONF.command.cmd_class.main()
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 74, in main
2015-01-08 08:29:56.494 TRACE keystone 
migration_helpers.sync_database_to_version(extension, version)
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 204, in 
sync_database_to_version
2015-01-08 08:29:56.494 TRACE keystone _sync_common_repo(version)
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 160, in 
_sync_common_repo
2015-01-08 08:29:56.494 TRACE keystone init_version=init_version)
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/oslo.db/oslo_db/sqlalchemy/migration.py, line 82, in db_sync
2015-01-08 08:29:56.494 TRACE keystone version)
2015-01-08 08:29:56.494 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py, line 202, 
in downgrade
2015-01-08 08:29:56.494 TRACE keystone return _migrate(url, repository, 
version, upgrade=False, err=err, **opts)
2015-01-08 08:29:56.494 TRACE keystone   File string, line 2, in _migrate
2015-01-08 08:29:56.494 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py, 
line 160, in with_engine
2015-01-08 08:29:56.494 TRACE keystone return f(*a, **kw)
2015-01-08 08:29:56.494 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py, line 366, 
in _migrate
2015-01-08 08:29:56.494 TRACE keystone schema.runchange(ver, change, 
changeset.step)
2015-01-08 08:29:56.494 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/migrate/versioning/schema.py, line 93, 
in runchange
2015-01-08 08:29:56.494 TRACE keystone change.run(self.engine, step)
2015-01-08 08:29:56.494 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/migrate/versioning/script/py.py, line 
148, in run
2015-01-08 08:29:56.494 TRACE keystone script_func(engine)
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migrate_repo/versions/061_add_parent_project.py,
 line 50, in downgrade
2015-01-08 08:29:56.494 TRACE keystone 
migration_helpers.remove_constraints(list_constraints(meta))
2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migrate_repo/versions/061_add_parent_project.py,
 line 24, in list_constraints
2015-01-08 08:29:56.494 TRACE keystone 'ref_column': project_table.c.id}]
2015-01-08 08:29:56.494 TRACE keystone AttributeError: 'MetaData' object has no 
attribute 'c'
2015-01-08 08:29:56.494 TRACE keystone

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1408658

Title:
  migration 61 downgrade fails using mysql

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  When trying to downgrade from version 61, it fails with an AttributeError.

  $ keystone-manage db_sync 60
  2015-01-08 08:29:56.494 CRITICAL keystone [-] AttributeError: 'MetaData' 
object has no attribute 'c'

  2015-01-08 08:29:56.494 TRACE keystone Traceback (most recent call last):
  2015-01-08 08:29:56.494 TRACE keystone   File 
/usr/local/bin/keystone-manage, line 6, in module
  2015-01-08 08:29:56.494 TRACE keystone 
exec(compile(open(__file__).read(), __file__, 'exec'))
  2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
  2015-01-08 08:29:56.494 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 311, in main
  2015-01-08 08:29:56.494 TRACE keystone CONF.command.cmd_class.main()
  2015-01-08 08:29:56.494 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 74, in main
  2015-01-08 08:29:56.494

[Yahoo-eng-team] [Bug 1408423] [NEW] Requirements are out of date

[Brant Knudson]

Public bug reported:

There have been several removals of code due to

1) switching to oslo libraries from oslo-incubator
2) not testing old versions of python-keystoneclient
3) deprecations getting removed, etc.

Along with these changes, one should look through requirements.txt and
test-requirements.txt to see if the requirements are still used, but it
looks like this hasn't happened so now we've got a bunch of things in
*requirements.txt which should be removed.

Having extra requirements listed makes it so that downstream packagers
might have extra unnecessary requirements on their packages. Also, if
the requirement isn't used by keystone or any of the other dependencies
then it won't need to be installed in the tox venv and make testing
faster.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1408423

Title:
  Requirements are out of date

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  There have been several removals of code due to

  1) switching to oslo libraries from oslo-incubator
  2) not testing old versions of python-keystoneclient
  3) deprecations getting removed, etc.

  Along with these changes, one should look through requirements.txt and
  test-requirements.txt to see if the requirements are still used, but
  it looks like this hasn't happened so now we've got a bunch of things
  in *requirements.txt which should be removed.

  Having extra requirements listed makes it so that downstream packagers
  might have extra unnecessary requirements on their packages. Also, if
  the requirement isn't used by keystone or any of the other
  dependencies then it won't need to be installed in the tox venv and
  make testing faster.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1408423/+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 1408389] [NEW] Tests shouldn't rely on provider registration by import

[Brant Knudson]

Public bug reported:


The tests shouldn't be relying on the provider being loaded by importing a 
module. When the server is actually run, it only imports the module if the 
extension is in the paste pipeline, and the tests shoud work similarly.

Also, tests shouldn't be using @dependency.requires to inject
dependencies -- this is for use by keystone server parts. The tests have
their own way of getting dependencies injected by loading the manager,
which is similar to how the Keystone server works.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1408389

Title:
  Tests shouldn't rely on provider registration by import

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  The tests shouldn't be relying on the provider being loaded by importing a 
module. When the server is actually run, it only imports the module if the 
extension is in the paste pipeline, and the tests shoud work similarly.

  Also, tests shouldn't be using @dependency.requires to inject
  dependencies -- this is for use by keystone server parts. The tests
  have their own way of getting dependencies injected by loading the
  manager, which is similar to how the Keystone server works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1408389/+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 1407273] [NEW] Unit tests failing with deprecation errors setuptools 10.2

[Brant Knudson]

Public bug reported:


setuptools 10.2 was released and it deprecated some commonly used function. 
Since we recently merged a change to error out when deprecations are used, this 
causes Keystone unit tests to fail.

The gate-keystone-python27 test contains errors  like:

 DeprecationWarning: `require` parameter is deprecated. Use
EntryPoint._load instead.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 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/1407273

Title:
  Unit tests failing with deprecation errors setuptools 10.2

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  setuptools 10.2 was released and it deprecated some commonly used function. 
Since we recently merged a change to error out when deprecations are used, this 
causes Keystone unit tests to fail.

  The gate-keystone-python27 test contains errors  like:

   DeprecationWarning: `require` parameter is deprecated. Use
  EntryPoint._load instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1407273/+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 1213106] Re: TypeError: an integer is required

[Brant Knudson]

The old code without the fix is in oslo.middleware . Ran into this when
trying to change Keystone to use oslo.middleware:
http://logs.openstack.org/97/144697/1/check/check-tempest-dsvm-
full/4a13e44/logs/apache/keystone.txt.gz#_2015-01-01_23_57_43_514 for
https://review.openstack.org/#/c/144697/

I ported the fix to oslo.middleware:
https://review.openstack.org/#/c/144700/


** Also affects: oslo.middleware
   Importance: Undecided
   Status: New

** Changed in: oslo.middleware
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: oslo.middleware
   Status: New = 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/1213106

Title:
  TypeError: an integer is required

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Oslo WSGI middleware library:
  In Progress

Bug description:
  2013-08-16 13:20:10ERROR [keystone.common.wsgi] an integer is required
  Traceback (most recent call last):
File /opt/keystone/keystone/common/wsgi.py, line 372, in __call__
  response = self.process_request(request)
File /opt/keystone/keystone/middleware/core.py, line 111, in 
process_request
  params_json = request.body
File /usr/lib/python2.7/dist-packages/webob/request.py, line 677, in 
_body__get
  self.make_body_seekable() # we need this to have content_length
File /usr/lib/python2.7/dist-packages/webob/request.py, line 922, in 
make_body_seekable
  self.copy_body()
File /usr/lib/python2.7/dist-packages/webob/request.py, line 938, in 
copy_body
  self.body = self.body_file_raw.read()
File /opt/keystone/keystone/common/utils.py, line 261, in read
  result = self.data.read(i)
  TypeError: an integer is required

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1213106/+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 1401664] [NEW] Update role using LDAP backend requires name

[Brant Knudson]

Public bug reported:


When updating a role and the keystone identity server is configured to use LDAP 
as the backend, you get a 500 error if the update doesn't have the name. For 
example, if you just disable a role, it fails with a 500 error.

0. Start with devstack configured to use LDAP assignment backend.

1. Get a token:

$ curl -i \
  -H Content-Type: application/json \
  -d '
{ auth: {
identity: {
  methods: [password],
  password: {
user: {
  name: admin,
  domain: { id: default },
  password: adminpwd
}
  }
},
scope: {
  project: {
name: demo,
domain: { id: default }
  }
}
  }
}' \
  http://localhost:35357/v3/auth/tokens ; echo

$ TOKEN=...

2. Pick a role.

$ curl \
-H X-Auth-Token: $TOKEN \
http://localhost:35357/v3/roles | python -m json.tool

$ ROLE_ID=36a9eede308d41e8a92effce2e46cc4a

3. Update without a name.

$ curl -X PATCH \
-H X-Auth-Token: $TOKEN \
-H Content-Type: application/json \
-d '{role: {enabled: false}}' \
http://localhost:35357/v3/roles/$ROLE_ID

{error: {message: An unexpected error prevented the server from
fulfilling your request: 'name' (Disable debug mode to suppress these
details.), code: 500, title: Internal Server Error}}


The update operation should be successful.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1401664

Title:
  Update role using LDAP backend requires name

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  When updating a role and the keystone identity server is configured to use 
LDAP as the backend, you get a 500 error if the update doesn't have the name. 
For example, if you just disable a role, it fails with a 500 error.

  0. Start with devstack configured to use LDAP assignment backend.

  1. Get a token:

  $ curl -i \
-H Content-Type: application/json \
-d '
  { auth: {
  identity: {
methods: [password],
password: {
  user: {
name: admin,
domain: { id: default },
password: adminpwd
  }
}
  },
  scope: {
project: {
  name: demo,
  domain: { id: default }
}
  }
}
  }' \
http://localhost:35357/v3/auth/tokens ; echo

  $ TOKEN=...

  2. Pick a role.

  $ curl \
  -H X-Auth-Token: $TOKEN \
  http://localhost:35357/v3/roles | python -m json.tool

  $ ROLE_ID=36a9eede308d41e8a92effce2e46cc4a

  3. Update without a name.

  $ curl -X PATCH \
  -H X-Auth-Token: $TOKEN \
  -H Content-Type: application/json \
  -d '{role: {enabled: false}}' \
  http://localhost:35357/v3/roles/$ROLE_ID

  {error: {message: An unexpected error prevented the server from
  fulfilling your request: 'name' (Disable debug mode to suppress these
  details.), code: 500, title: Internal Server Error}}

  
  The update operation should be successful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1401664/+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 1401721] [NEW] Update role using LDAP backend with same name fails

[Brant Knudson]

Public bug reported:


When the keystone server is configured to use the LDAP backend for assignments 
and a role is updated to have the same name the operation fails saying that you 
can't create a role because another role with the same name already exists.

The keystone server should just accept the request and ignore the change
rather than failing.

To recreate:

0. Start with a devstack install using LDAP for assignment backend

1. Get a token

$ curl -i \
  -H Content-Type: application/json \
  -d '
{ auth: {
identity: {
  methods: [password],
  password: {
user: {
  name: admin,
  domain: { id: default },
  password: adminpwd
}
  }
},
scope: {
  project: {
name: demo,
domain: { id: default }
  }
}
  }
}' \
  http://localhost:35357/v3/auth/tokens ; echo

$ TOKEN=...

2. List roles

$ curl \
-H X-Auth-Token: $TOKEN \
http://localhost:35357/v3/roles | python -m json.tool

$ ROLE_ID=36a9eede308d41e8a92effce2e46cc4a

3. Update a role with the same name.

$ curl -X PATCH \
-H X-Auth-Token: $TOKEN \
-H Content-Type: application/json \
-d '{role: {name: anotherrole}}' \
http://localhost:35357/v3/roles/$ROLE_ID

{error: {message: Cannot duplicate name {'id':
u'36a9eede308d41e8a92effce2e46cc4a', 'name': u'anotherrole'}, code:
409, title: Conflict}}

The operation should have worked.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1401721

Title:
  Update role using LDAP backend with same name fails

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  When the keystone server is configured to use the LDAP backend for 
assignments and a role is updated to have the same name the operation fails 
saying that you can't create a role because another role with the same name 
already exists.

  The keystone server should just accept the request and ignore the
  change rather than failing.

  To recreate:

  0. Start with a devstack install using LDAP for assignment backend

  1. Get a token

  $ curl -i \
-H Content-Type: application/json \
-d '
  { auth: {
  identity: {
methods: [password],
password: {
  user: {
name: admin,
domain: { id: default },
password: adminpwd
  }
}
  },
  scope: {
project: {
  name: demo,
  domain: { id: default }
}
  }
}
  }' \
http://localhost:35357/v3/auth/tokens ; echo

  $ TOKEN=...

  2. List roles

  $ curl \
  -H X-Auth-Token: $TOKEN \
  http://localhost:35357/v3/roles | python -m json.tool

  $ ROLE_ID=36a9eede308d41e8a92effce2e46cc4a

  3. Update a role with the same name.

  $ curl -X PATCH \
  -H X-Auth-Token: $TOKEN \
  -H Content-Type: application/json \
  -d '{role: {name: anotherrole}}' \
  http://localhost:35357/v3/roles/$ROLE_ID

  {error: {message: Cannot duplicate name {'id':
  u'36a9eede308d41e8a92effce2e46cc4a', 'name': u'anotherrole'}, code:
  409, title: Conflict}}

  The operation should have worked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1401721/+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 1395368] Re: ExternalNetworksTest[JSON, XML].test_delete_external_networks_with_floating_ip failures

[Brant Knudson]

Since https://review.openstack.org/#/c/135903/ is merged things seem to
be working again.

** No longer affects: keystonemiddleware

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1395368

Title:
  ExternalNetworksTest[JSON,XML].test_delete_external_networks_with_floating_ip
  failures

Status in OpenStack Neutron (virtual network service):
  New
Status in Python client library for Glance:
  New
Status in Tempest:
  Incomplete

Bug description:
  I'm unsure as to the root cause (looking through the basic neutron,
  nova api logs didn't show much usefulness around the times these
  failed)...

  Here is the full log and link though:

  http://logs.openstack.org/51/136551/2/check/gate-tempest-dsvm-neutron-
  src-taskflow-icehouse/8e0bb9f/

  2014-11-22 18:50:53.315 | {1}
  
tempest.api.network.admin.test_external_network_extension.ExternalNetworksTestJSON.test_delete_external_networks_with_floating_ip
  [0.984493s] ... FAILED

  ft333.2: 
tempest.api.network.admin.test_external_network_extension.ExternalNetworksTestXML.test_delete_external_networks_with_floating_ip_StringException:
 pythonlogging:'': {{{
  2014-11-22 18:54:54,689 2113 DEBUG[tempest.common.rest_client] Request 
(ExternalNetworksTestXML:test_delete_external_networks_with_floating_ip): 201 
POST http://127.0.0.1:9696/v2.0/networks 0.080s
  Request - Headers: {'Content-Type': 'application/xml', 'Accept': 
'application/xml', 'X-Auth-Token': 'omitted'}
  Body: ?xml version=1.0 encoding=UTF-8?
  network xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xmlns:router=http://docs.openstack.org/ext/neutron/router/api/v1.0;router:external
 True/router:external/network
  Response - Headers: {'status': '201', 'content-length': '805', 
'connection': 'close', 'date': 'Sat, 22 Nov 2014 18:54:54 GMT', 'content-type': 
'application/xml; charset=UTF-8', 'x-openstack-request-id': 
'req-9d70cf16-d0ae-46e6-9f40-9c68cc50a2f0'}
  Body: ?xml version='1.0' encoding='UTF-8'?
  network xmlns=http://openstack.org/quantum/api/v2.0; 
xmlns:provider=http://docs.openstack.org/ext/provider/api/v1.0; 
xmlns:quantum=http://openstack.org/quantum/api/v2.0; 
xmlns:router=http://docs.openstack.org/ext/neutron/router/api/v1.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;statusACTIVE/statussubnets
 quantum:type=list /name /provider:physical_network xsi:nil=true 
/admin_state_up 
quantum:type=boolTrue/admin_state_uptenant_ida3451f42641c4a3ab319253134e5a036/tenant_idprovider:network_typelocal/provider:network_typerouter:external
 quantum:type=boolTrue/router:externalshared 
quantum:type=boolFalse/sharedid0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/idprovider:segmentation_id
 xsi:nil=true //network
  2014-11-22 18:54:54,789 2113 DEBUG[tempest.common.rest_client] Request 
(ExternalNetworksTestXML:test_delete_external_networks_with_floating_ip): 201 
POST http://127.0.0.1:9696/v2.0/subnets 0.098s
  Request - Headers: {'Content-Type': 'application/xml', 'Accept': 
'application/xml', 'X-Auth-Token': 'omitted'}
  Body: ?xml version=1.0 encoding=UTF-8?
  subnet xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;ip_version 
4/ip_versionnetwork_id 
0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/network_idcidr 
10.100.0.0/28/cidrgateway_ip 10.100.0.1/gateway_ip/subnet
  Response - Headers: {'status': '201', 'content-length': '729', 
'connection': 'close', 'date': 'Sat, 22 Nov 2014 18:54:54 GMT', 'content-type': 
'application/xml; charset=UTF-8', 'x-openstack-request-id': 
'req-4f27ac74-c53f-4dd7-bd90-7bb217c82626'}
  Body: ?xml version='1.0' encoding='UTF-8'?
  subnet xmlns=http://openstack.org/quantum/api/v2.0; 
xmlns:quantum=http://openstack.org/quantum/api/v2.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;name /enable_dhcp 
quantum:type=boolTrue/enable_dhcpnetwork_id0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/network_idtenant_ida3451f42641c4a3ab319253134e5a036/tenant_iddns_nameservers
 quantum:type=list 
/allocation_poolsallocation_poolstart10.100.0.2/startend10.100.0.14/end/allocation_pool/allocation_poolshost_routes
 quantum:type=list /ip_version 
quantum:type=int4/ip_versiongateway_ip10.100.0.1/gateway_ipcidr10.100.0.0/28/cidrid49d84272-4d7e-49fd-bf72-0dcf7c923db6/id/subnet
  2014-11-22 18:54:54,877 2113 DEBUG[tempest.common.rest_client] Request 
(ExternalNetworksTestXML:test_delete_external_networks_with_floating_ip): 201 
POST http://127.0.0.1:9696/v2.0/floatingips 0.087s
  Request - Headers: {'Content-Type': 'application/xml', 'Accept': 
'application/xml', 'X-Auth-Token': 'omitted'}
  Body: ?xml version=1.0 encoding=UTF-8?
  floatingip 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;floating_network_id 
0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/floating_network_id/floatingip
  Response - Headers: {'status': '201', 'content-length': '560', 
'connection': 'close', 'date': 'Sat, 22 Nov 2014 18:54:54 GMT', 

[Yahoo-eng-team] [Bug 1374497] Re: change in oslo.db ping handling is causing issues in projects that are not using transactions

[Brant Knudson]

There's a fix in oslo.db. The work to update Keystone will be part of a
spec or blueprint to use new features in oslo.db once they're ready. I
don't think it's worth keeping a bug open.

** Changed in: keystone
   Status: Triaged = Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1374497

Title:
  change in oslo.db ping handling is causing issues in projects that
  are not using transactions

Status in OpenStack Identity (Keystone):
  Won't Fix
Status in Oslo Database library:
  Fix Released
Status in oslo.db juno series:
  Fix Released

Bug description:
  in https://review.openstack.org/#/c/106491/, the ping listener which
  emits SELECT 1 at connection start was moved from being a connection
  pool checkout handler to a transaction on begin handler.
  Apparently Keystone and possibly others are using the Session in
  autocommit mode, despite that this is explicitly warned against in
  SQLAlchemy's docs (see
  http://docs.sqlalchemy.org/en/rel_0_9/orm/session.html#autocommit-
  mode), and for these projects they are seeing failed connections not
  transparently recovered (see
  https://bugs.launchpad.net/keystone/+bug/1361378).

  Alternatives include:

  1. move the ping listener back to being a checkout handler

  2. fix downstream projects to not use the session in autocommit mode

  In all likelihood, the fix here should involve both.   I have a longer
  term plan to fix EngineFacade once and for all so that the correct use
  patterns are explicit, but that still has to be blueprinted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1374497/+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 1386773] [NEW] Project details request with long ID causes 500 error with DB2

[Brant Knudson]

Public bug reported:


When using DB2 as the database, if you get project details with a really long 
ID (even if it doesn't exist), the you get a 500 error instead of 404 Not Found:

 $ curl -s -H X-Auth-Token: $TOKEN 
http://localhost:35357/v3/projects/915eb1fb90d34430b1dafbc712889924asldkjsalkfdjlaksdjflkdsajflkdsajfdsasad
 | python -m json.tool
{
error: {
code: 500,
message: An unexpected error prevented the server from fulfilling 
your request: (DataError) ibm_db_dbi::DataError: Statement Execute Failed: 
[IBM][CLI Driver] CLI0109E  String data right truncation. SQLSTATE=22001 
SQLCODE=-9 'SELECT project.id AS project_id, project.name AS project_name, 
project.domain_id AS project_domain_id, project.description AS 
project_description, project.enabled AS project_enabled, project.extra AS 
project_extra \\nFROM project \\nWHERE project.id = ?' 
('915eb1fb90d34430b1dafbc712889924asldkjsalkfdjlaksdjflkdsajflkdsajfdsasad',) 
(Disable debug mode to suppress these details.),
title: Internal Server Error
}
}

I guess DB2 doesn't like getting a parameter that's longer than the
column.

This probably applies to other resources, too.

Seems like the right thing to do here is either check the length in the
SQL backend or catch this particular exception and reraise it as
NotFound. Seems safer and more efficient to check the length in the SQL
backend, although it's going to be a lot of changes.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1386773

Title:
  Project details request with long ID causes 500 error with DB2

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  When using DB2 as the database, if you get project details with a really long 
ID (even if it doesn't exist), the you get a 500 error instead of 404 Not Found:

   $ curl -s -H X-Auth-Token: $TOKEN 
http://localhost:35357/v3/projects/915eb1fb90d34430b1dafbc712889924asldkjsalkfdjlaksdjflkdsajflkdsajfdsasad
 | python -m json.tool
  {
  error: {
  code: 500,
  message: An unexpected error prevented the server from fulfilling 
your request: (DataError) ibm_db_dbi::DataError: Statement Execute Failed: 
[IBM][CLI Driver] CLI0109E  String data right truncation. SQLSTATE=22001 
SQLCODE=-9 'SELECT project.id AS project_id, project.name AS project_name, 
project.domain_id AS project_domain_id, project.description AS 
project_description, project.enabled AS project_enabled, project.extra AS 
project_extra \\nFROM project \\nWHERE project.id = ?' 
('915eb1fb90d34430b1dafbc712889924asldkjsalkfdjlaksdjflkdsajflkdsajfdsasad',) 
(Disable debug mode to suppress these details.),
  title: Internal Server Error
  }
  }

  I guess DB2 doesn't like getting a parameter that's longer than the
  column.

  This probably applies to other resources, too.

  Seems like the right thing to do here is either check the length in
  the SQL backend or catch this particular exception and reraise it as
  NotFound. Seems safer and more efficient to check the length in the
  SQL backend, although it's going to be a lot of changes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1386773/+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 1372422] Re: Glance exploding on configuration parsing

[Brant Knudson]

Sean - I didn't backport the change(s) to use keystonemiddleware... I
can see reasons for backporting it or not backporting, so am not sure
what the right thing to do is.

I think it's best to look into what changed in keystoneclient.middleware
recently... I'll try it with glance in devstack.

** Also affects: python-keystoneclient
   Importance: Undecided
   Status: New

** No longer affects: keystone

** Changed in: python-keystoneclient
   Importance: Undecided = Critical

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1372422

Title:
  Glance exploding on configuration parsing

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in Python client library for Keystone:
  New

Bug description:
  From recent various test runs:

  2014-09-22 09:10:52.763 21744 INFO glance.notifier.notify_kombu [-] Connected 
to AMQP server on localhost:5672
  2014-09-22 09:10:52.763 21744 INFO glance.api.middleware.cache [-] 
Initialized image cache middleware
  2014-09-22 09:10:52.764 21744 INFO keystoneclient.middleware.auth_token [-] 
Starting keystone auth_token middleware
  2014-09-22 09:10:52.764 21744 WARNING keystoneclient.middleware.auth_token 
[-] This middleware module is deprecated as of v0.10.0 in favor of 
keystonemiddleware.auth_token - please update your WSGI pipeline to reference 
the new middleware package.
  2014-09-22 09:10:52.764 21744 CRITICAL glance [-] 'StrOpt' object has no 
attribute 'type'

  Then glance-api crashes. The sanity checks in devstack realize that
  glance isn't running and exit.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1372422/+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 1200777] Re: No V3 extensions list

[Brant Knudson]

We won't have a v3 extensions like v2 extensions, since you can do
extension discovery using the JSON Home document.

** Changed in: keystone
   Status: Confirmed = Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1200777

Title:
  No V3 extensions list

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  /v2.0/extensions is supported, but

  http://localhost:35357/v3/extentions returns a 404

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1200777/+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 1366944] [NEW] Man pages out of date

[Brant Knudson]

Public bug reported:

The man pages for keystone-all and keystone-manage are out of date.
especially keystone-manage is missing new subcommands.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: keystone
Milestone: None = juno-rc1

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1366944

Title:
  Man pages out of date

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The man pages for keystone-all and keystone-manage are out of date.
  especially keystone-manage is missing new subcommands.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366944/+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 1366589] [NEW] JSON Home support for GET /

[Brant Knudson]

Public bug reported:

Keystone supports getting a JSON Home document for GET /v3. It should
also support returning the JSON Home for GET /, that way a client that
supports JSON Home and is pointed to the / endpoint doesn't have to then
fetch /v3.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
Milestone: None = juno-rc1

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: keystone
   Status: New = 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/1366589

Title:
  JSON Home support for GET /

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Keystone supports getting a JSON Home document for GET /v3. It should
  also support returning the JSON Home for GET /, that way a client that
  supports JSON Home and is pointed to the / endpoint doesn't have to
  then fetch /v3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366589/+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 1366594] [NEW] config generator using keystoneclient rather than middleware

[Brant Knudson]

Public bug reported:

The auth_token middleware was moved from keystoneclient.middleware to
keystonemiddleware.
http://git.openstack.org/cgit/openstack/nova/tree/tools/config/oslo.config.generator.rc
should be updated to use keystonemiddleware.

** Affects: nova
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: nova
   Status: New = In Progress

** Changed in: nova
 Assignee: (unassigned) = Brant Knudson (blk-u)

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

Title:
  config generator using keystoneclient rather than middleware

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  The auth_token middleware was moved from keystoneclient.middleware to
  keystonemiddleware.
  
http://git.openstack.org/cgit/openstack/nova/tree/tools/config/oslo.config.generator.rc
  should be updated to use keystonemiddleware.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366594/+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 1366606] [NEW] oauth1 downgrade fail with sqlite

[Brant Knudson]

Public bug reported:


The oauth1 extension migrations fail with sqlite when doing the version 2 
downgrade. This is because the migration is attempting to compare a string to 
an sqlalchemy Engine object.

NotSupportedError: SQLite does not support ALTER TABLE DROP CONSTRAINT;
see http://www.sqlite.org/lang_altertable.html

** Affects: keystone
 Importance: Low
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: keystone
Milestone: None = juno-rc1

** Changed in: keystone
   Status: New = In Progress

** Changed in: keystone
   Importance: Undecided = Low

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1366606

Title:
  oauth1 downgrade fail with sqlite

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  The oauth1 extension migrations fail with sqlite when doing the version 2 
downgrade. This is because the migration is attempting to compare a string to 
an sqlalchemy Engine object.

  NotSupportedError: SQLite does not support ALTER TABLE DROP
  CONSTRAINT; see http://www.sqlite.org/lang_altertable.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366606/+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 1366062] Re: ldappool is not present in requirements.txt

[Brant Knudson]

It's in test-requirements.txt.

** Changed in: keystone
   Status: In Progress = Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1366062

Title:
  ldappool is not present in requirements.txt

Status in OpenStack Identity (Keystone):
  Won't Fix

Bug description:
  ldappool package is imported in keystone/common/ldap/core.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366062/+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 1366211] [NEW] Using LDAP assignments, delete group doesn't remove assignments

[Brant Knudson]

Public bug reported:


When Keystone is configured to use the LDAP backend for assignments, if a group 
with a role assignment is deleted then the role assignments are not deleted as 
they should be.

See bug 1365787 for instructions on creating the group role assignment.

Here's an example where I set up a group role assignment:

$ openstack role assignment list
+--+--+--+--++
| Role | User | Group   
 | Project  | Domain |
+--+--+--+--++
...
| fc4bf67b5d004581b375b98bbc31af38 |  | 
ae467ef324584807894ab52566db41f4 | 31e82447e7b2415f934a328e121595ce ||
+--+--+--+--++
bknudson@f1-ds:~$ openstack group delete blktest1
bknudson@f1-ds:~$ openstack role assignment list
+--+--+--+--++
| Role | User | Group   
 | Project  | Domain |
+--+--+--+--++
| fc4bf67b5d004581b375b98bbc31af38 |  | 
ae467ef324584807894ab52566db41f4 | 31e82447e7b2415f934a328e121595ce ||
+--+--+--+--++

That role assignment shouldn't be there anymore.

** 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/1366211

Title:
  Using LDAP assignments, delete group doesn't remove assignments

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  When Keystone is configured to use the LDAP backend for assignments, if a 
group with a role assignment is deleted then the role assignments are not 
deleted as they should be.

  See bug 1365787 for instructions on creating the group role
  assignment.

  Here's an example where I set up a group role assignment:

  $ openstack role assignment list
  
+--+--+--+--++
  | Role | User | Group 
   | Project  | Domain |
  
+--+--+--+--++
  ...
  | fc4bf67b5d004581b375b98bbc31af38 |  | 
ae467ef324584807894ab52566db41f4 | 31e82447e7b2415f934a328e121595ce ||
  
+--+--+--+--++
  bknudson@f1-ds:~$ openstack group delete blktest1
  bknudson@f1-ds:~$ openstack role assignment list
  
+--+--+--+--++
  | Role | User | Group 
   | Project  | Domain |
  
+--+--+--+--++
  | fc4bf67b5d004581b375b98bbc31af38 |  | 
ae467ef324584807894ab52566db41f4 | 31e82447e7b2415f934a328e121595ce ||
  
+--+--+--+--++

  That role assignment shouldn't be there anymore.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366211/+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 1361125] Re: keystone install failed, meet error 'got an unexpected keyword argument 'namedtuple_as_object''

[Brant Knudson]

*** This bug is a duplicate of bug 1361230 ***
https://bugs.launchpad.net/bugs/1361230

Dolph - it's 94efafd6 that introduced the problem in Keystone. This is a
duplicate of bug 1361230 .

** This bug has been marked a duplicate of bug 1361230
   ad248f6 jsonutils sync breaks if simplejson  2.2.0 (under python 2.6)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1361125

Title:
  keystone install failed, meet error 'got an unexpected keyword
  argument 'namedtuple_as_object''

Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  My env:
  OS: RHEL 6.5 x86-64
  Pthon: 2.6.6
  Source branch: master

  error log:
  2014-08-25 07:30:34.256 | 5298 DEBUG migrate.versioning.repository [-] 
Repository /opt/stack/keystone/keystone/common/sql/migrate_repo loaded 
successfully __init__ 
/usr/lib/python2.6/site-packages/migrate/versioning/repository.py:82
  2014-08-25 07:30:34.256 | 5298 DEBUG migrate.versioning.repository [-] 
Config: {'db_settings': {'__name__': 'db_settings', 'use_timestamp_numbering': 
'False', 'required_dbs': '[]', 'version_table': 'migrate_version', 
'repository_id': 'keystone'}} __init__ 
/usr/lib/python2.6/site-packages/migrate/versioning/repository.py:83
  2014-08-25 07:30:34.256 | 5298 INFO migrate.versioning.api [-] 35 - 36...
  2014-08-25 07:30:35.142 | 5298 CRITICAL keystone [-] TypeError: __init__() 
got an unexpected keyword argument 'namedtuple_as_object'
  2014-08-25 07:30:35.142 | 5298 TRACE keystone Traceback (most recent call 
last):
  2014-08-25 07:30:35.142 | 5298 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
  2014-08-25 07:30:35.142 | 5298 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 292, in main
  2014-08-25 07:30:35.143 | 5298 TRACE keystone 
CONF.command.cmd_class.main()
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 74, in main
  2014-08-25 07:30:35.143 | 5298 TRACE keystone 
migration_helpers.sync_database_to_version(extension, version)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 204, in 
sync_database_to_version
  2014-08-25 07:30:35.143 | 5298 TRACE keystone _sync_common_repo(version)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 160, in 
_sync_common_repo
  2014-08-25 07:30:35.143 | 5298 TRACE keystone init_version=init_version)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/usr/lib/python2.6/site-packages/oslo/db/sqlalchemy/migration.py, line 79, in 
db_sync
  2014-08-25 07:30:35.143 | 5298 TRACE keystone return 
versioning_api.upgrade(engine, repository, version)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/usr/lib/python2.6/site-packages/migrate/versioning/api.py, line 186, in 
upgrade
  2014-08-25 07:30:35.143 | 5298 TRACE keystone return _migrate(url, 
repository, version, upgrade=True, err=err, **opts)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File string, line 2, in 
_migrate
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/usr/lib/python2.6/site-packages/migrate/versioning/util/__init__.py, line 
160, in with_engine
  2014-08-25 07:30:35.143 | 5298 TRACE keystone return f(*a, **kw)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/usr/lib/python2.6/site-packages/migrate/versioning/api.py, line 366, in 
_migrate
  2014-08-25 07:30:35.143 | 5298 TRACE keystone schema.runchange(ver, 
change, changeset.step)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/usr/lib/python2.6/site-packages/migrate/versioning/schema.py, line 93, in 
runchange
  2014-08-25 07:30:35.143 | 5298 TRACE keystone change.run(self.engine, 
step)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/usr/lib/python2.6/site-packages/migrate/versioning/script/py.py, line 148, 
in run
  2014-08-25 07:30:35.143 | 5298 TRACE keystone script_func(engine)
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migrate_repo/versions/036_havana.py, 
line 283, in upgrade
  2014-08-25 07:30:35.143 | 5298 TRACE keystone 
domain.insert(migration_helpers.get_default_domain()).execute()
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 47, in 
get_default_domain
  2014-08-25 07:30:35.143 | 5298 TRACE keystone 'extra': 
jsonutils.dumps({'description': 'Owns users and tenants '
  2014-08-25 07:30:35.143 | 5298 TRACE keystone   File 
/opt/stack/keystone/keystone/openstack/common/jsonutils.py, line 172, in dumps
  2014-08-25 07:30:35.143 | 5298 TRACE keystone return json.dumps(value, 
default=default, 

[Yahoo-eng-team] [Bug 1365787] [NEW] LDAP group role assignment becomes user assignment

[Brant Knudson]

Public bug reported:

When I configure Keystone with the LDAP backend, creating a group role
assignment winds up being a user role assignment.

Here's steps to recreate:

Start with devstack configured to use LDAP

$ openstack group create blktest1
+---+--+
| Field | Value 
   |
+---+--+
| domain_id | default   
   |
| id| 33888a7d75274497bb1e7a05fc17a748  
   |
| links | {u'self': 
u'http://192.168.122.176:5000/v3/groups/33888a7d75274497bb1e7a05fc17a748'} |
| name  | blktest1  
   |
+---+--+

$ GROUP_ID=33888a7d75274497bb1e7a05fc17a748

$ openstack role list
| 1fbe54e498ad483cb900735715926032 | anotherrole   |

$ ROLE_ID=1fbe54e498ad483cb900735715926032

$ openstack project list
| 111681b688eb4460b464745f461ad0ce | demo   |

PROJECT_ID=111681b688eb4460b464745f461ad0ce

# Get a token since I can't find an openstack command to add role
assignment...

$ curl ...

$ TOKEN=PKIZ...

# Create the GROUP role assignment

$ curl -i -X PUT  -H X-Auth-Token: $TOKEN \
 http://localhost:35357/v3/projects/$PROJECT_ID/groups/$GROUP_ID/roles/$ROLE_ID
HTTP/1.1 204 No Content

# Check the results. Now it's a user role assignment.

$ openstack role assignment list
+--+--+---+--++
| Role | User | Group | 
Project  | Domain |
+--+--+---+--++
| 9fe2ff9ee4384b1894a90878d3e92bab | 6e045e61b335473f9806460fcbf06b08 |   | 
4b78eb4768924d8ba492e53eecddf493 ||
| 29b0254e79d141d1a342086fd772e5f4 | 6e045e61b335473f9806460fcbf06b08 |   | 
4b78eb4768924d8ba492e53eecddf493 ||
| 9fe2ff9ee4384b1894a90878d3e92bab | 8fa4aa9d5584421eb8fa22ad01ff806a |   | 
111681b688eb4460b464745f461ad0ce ||
| 04b98b07af274304b19ce3e7d18de881 | 8fa4aa9d5584421eb8fa22ad01ff806a |   | 
111681b688eb4460b464745f461ad0ce ||
| 29b0254e79d141d1a342086fd772e5f4 | 6e045e61b335473f9806460fcbf06b08 |   | 
111681b688eb4460b464745f461ad0ce ||
| 1fbe54e498ad483cb900735715926032 | 8fa4aa9d5584421eb8fa22ad01ff806a |   | 
111681b688eb4460b464745f461ad0ce ||
| 1fbe54e498ad483cb900735715926032 | 33888a7d75274497bb1e7a05fc17a748 |   | 
111681b688eb4460b464745f461ad0ce ||
| 04b98b07af274304b19ce3e7d18de881 | 8fa4aa9d5584421eb8fa22ad01ff806a |   | 
7dee56223a5d43169ba1c5a2ac8ec412 ||
+--+--+---+--++

# Also check the REST response since maybe it's in openstack command:

$ curl -H X-Auth-Token: $TOKEN
http://localhost:5000/v3/role_assignments | python -mjson.tool

...
{
links: {
assignment: 
http://192.168.122.176:5000/v3/projects/111681b688eb4460b464745f461ad0ce/users/33888a7d75274497bb1e7a05fc17a748/roles/1fbe54e498ad483cb900735715926032;
},
role: {
id: 1fbe54e498ad483cb900735715926032
},
scope: {
project: {
id: 111681b688eb4460b464745f461ad0ce
}
},
user: {
id: 33888a7d75274497bb1e7a05fc17a748
}
},
...

It's got user where it should be group.

** 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/1365787

Title:
  LDAP group role assignment becomes user assignment

Status in OpenStack Identity (Keystone):
  New

Bug description:
  When I configure Keystone with the LDAP backend, creating a group role
  assignment winds up being a user role assignment.

  Here's steps to recreate:

  Start with devstack configured to use LDAP

  $ openstack group create blktest1
  
+---+--+
  | Field | Value   
 |
  
+---+--+
  | domain_id | default 
 |
  | id| 33888a7d75274497bb1e7a05fc17a748
 |
  | links | {u'self': 

[Yahoo-eng-team] [Bug 1363704] [NEW] notification registration log should be debug

[Brant Knudson]

Public bug reported:


When the Keystone server starts, there's several log messages:

2014-08-31 12:45:24.686 INFO keystone.notifications [-] Callback: 
`keystone.token.provider.Manager._trust_deleted_event_callback` subscribed to 
event `identity.OS-TRUST:trust.deleted`.
...

I can't think of a reason why an administrator would find it necessary
to know that some internal callback registrations occurred. If somebody
is, they can use logging configuration to enable it.

** Affects: keystone
 Importance: Low
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: keystone
Milestone: None = juno-3

** Changed in: keystone
   Importance: Undecided = Low

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1363704

Title:
  notification registration log should be debug

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  When the Keystone server starts, there's several log messages:

  2014-08-31 12:45:24.686 INFO keystone.notifications [-] Callback: 
`keystone.token.provider.Manager._trust_deleted_event_callback` subscribed to 
event `identity.OS-TRUST:trust.deleted`.
  ...

  I can't think of a reason why an administrator would find it necessary
  to know that some internal callback registrations occurred. If
  somebody is, they can use logging configuration to enable it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1363704/+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 1363709] [NEW] keystone-all logging config twice

[Brant Knudson]

Public bug reported:


keystone-all is logging the config twice. Once from keystone-all and once from 
keystone.openstack.common.service.

The config should only has to be logged once.

** Affects: keystone
 Importance: Low
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Brant Knudson (blk-u)

** Changed in: keystone
Milestone: None = juno-3

** Changed in: keystone
   Importance: Undecided = Low

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1363709

Title:
  keystone-all logging config twice

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  keystone-all is logging the config twice. Once from keystone-all and once 
from keystone.openstack.common.service.

  The config should only has to be logged once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1363709/+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 1363224] [NEW] token_flush is failing with recursion depth error

[Brant Knudson]

Public bug reported:


When I run `keystone-manage token_flush` on a new devstack install, it fails 
with a recursion depth error:

$ keystone-manage token_flush
2014-08-29 14:21:58.933 CRITICAL keystone [-] RuntimeError: maximum recursion 
depth exceeded while calling a Python object

2014-08-29 14:21:58.933 TRACE keystone Traceback (most recent call last):
2014-08-29 14:21:58.933 TRACE keystone   File /usr/local/bin/keystone-manage, 
line 6, in module
2014-08-29 14:21:58.933 TRACE keystone exec(compile(open(__file__).read(), 
__file__, 'exec'))
2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
2014-08-29 14:21:58.933 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 292, in main
2014-08-29 14:21:58.933 TRACE keystone CONF.command.cmd_class.main()
2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 176, in main
2014-08-29 14:21:58.933 TRACE keystone 
token_manager.driver.flush_expired_tokens()
2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/token/persistence/core.py, line 231, in 
__getattr__
2014-08-29 14:21:58.933 TRACE keystone f = 
getattr(self.token_provider_api._persistence, item)
...
2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/token/persistence/core.py, line 231, in 
__getattr__
2014-08-29 14:21:58.933 TRACE keystone f = 
getattr(self.token_provider_api._persistence, item)
2014-08-29 14:21:58.933 TRACE keystone RuntimeError: maximum recursion depth 
exceeded while calling a Python object

** 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/1363224

Title:
  token_flush is failing with recursion depth error

Status in OpenStack Identity (Keystone):
  New

Bug description:
  
  When I run `keystone-manage token_flush` on a new devstack install, it fails 
with a recursion depth error:

  $ keystone-manage token_flush
  2014-08-29 14:21:58.933 CRITICAL keystone [-] RuntimeError: maximum recursion 
depth exceeded while calling a Python object

  2014-08-29 14:21:58.933 TRACE keystone Traceback (most recent call last):
  2014-08-29 14:21:58.933 TRACE keystone   File 
/usr/local/bin/keystone-manage, line 6, in module
  2014-08-29 14:21:58.933 TRACE keystone 
exec(compile(open(__file__).read(), __file__, 'exec'))
  2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
  2014-08-29 14:21:58.933 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 292, in main
  2014-08-29 14:21:58.933 TRACE keystone CONF.command.cmd_class.main()
  2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 176, in main
  2014-08-29 14:21:58.933 TRACE keystone 
token_manager.driver.flush_expired_tokens()
  2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/token/persistence/core.py, line 231, in 
__getattr__
  2014-08-29 14:21:58.933 TRACE keystone f = 
getattr(self.token_provider_api._persistence, item)
  ...
  2014-08-29 14:21:58.933 TRACE keystone   File 
/opt/stack/keystone/keystone/token/persistence/core.py, line 231, in 
__getattr__
  2014-08-29 14:21:58.933 TRACE keystone f = 
getattr(self.token_provider_api._persistence, item)
  2014-08-29 14:21:58.933 TRACE keystone RuntimeError: maximum recursion depth 
exceeded while calling a Python object

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1363224/+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