[Yahoo-eng-team] [Bug 1672597] [NEW] [live migration] The instance directory on the destination host is not clean up

[Dave Chen]

Public bug reported:

I understand there are code to clean up the instance directory on the
target host if the live migration failed, but the directory is not
cleanup if libvirt's connection is timeout.

I haven't got a change to root cause the issue, but I feel the code
could be optimized a little bit to avoid this issue.

Here is some trace log from my side.

- Libvirt connection timed out
2017-03-07 02:34:37.540 ERROR nova.virt.libvirt.driver 
[req-35bc9ca8-c77b-481c-ae3e-93bbfed6187f admin admin] [instance: 
6714b056-4950-4e63-83d3-fc383e977a53] Live Migration failure: unable to connect 
to server at 'ceph-dev:49152': Connection timed out
2017-03-07 02:34:37.541 DEBUG nova.virt.libvirt.driver 
[req-35bc9ca8-c77b-481c-ae3e-93bbfed6187f admin admin] [instance: 
6714b056-4950-4e63-83d3-fc383e977a53] Migration operation thread notification 
from (pid=18073) thread_finished 
/opt/stack/nova/nova/virt/libvirt/driver.py:6361
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 457, 
in fire_timers
timer()
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/timer.py", line 
58, in __call__
cb(*args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line 168, in 
_do_send
waiter.switch(result)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 
214, in main
result = function(*args, **kwargs)
  File "/opt/stack/nova/nova/utils.py", line 1066, in context_wrapper
return func(*args, **kwargs)
  File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5962, in 
_live_migration_operation
instance=instance)
  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
220, in __exit__
self.force_reraise()
  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5958, in 
_live_migration_operation
bandwidth=CONF.libvirt.live_migration_bandwidth)
  File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 605, in migrate
flags=flags, bandwidth=bandwidth)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in 
doit
result = proxy_call(self._autowrap, f, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in 
proxy_call
rv = execute(f, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in 
execute
six.reraise(c, e, tb)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in 
tworker
rv = meth(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1586, in 
migrateToURI2
if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed', 
dom=self)

libvirtError: unable to connect to server at 'ceph-dev:49152':
Connection timed out


- The instance's directory haven't cleanup, and the next migration will fail.

Traceback (most recent call last):

  File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", 
line 133, in _process_incoming
res = self.dispatcher.dispatch(message)

  File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
150, in dispatch
return self._do_dispatch(endpoint, method, ctxt, args)

  File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
121, in _do_dispatch
result = func(ctxt, **new_args)

  File "/opt/stack/nova/nova/exception_wrapper.py", line 75, in wrapped
function_name, call_dict, binary)

  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
220, in __exit__
self.force_reraise()

  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
196, in force_reraise
six.reraise(self.type_, self.value, self.tb)

  File "/opt/stack/nova/nova/exception_wrapper.py", line 66, in wrapped
return f(self, context, *args, **kw)

  File "/opt/stack/nova/nova/compute/utils.py", line 613, in decorated_function
return function(self, context, *args, **kwargs)

  File "/opt/stack/nova/nova/compute/manager.py", line 216, in 
decorated_function
kwargs['instance'], e, sys.exc_info())

  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
220, in __exit__
self.force_reraise()

  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
196, in force_reraise
six.reraise(self.type_, self.value, self.tb)

  File "/opt/stack/nova/nova/compute/manager.py", line 204, in 
decorated_function
return function(self, context, *args, **kwargs)

  File "/opt/stack/nova/nova/compute/manager.py", line 5192, in 
pre_live_migration
migrate_data)

  File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 6474, in 
pre_live_migration
raise exception.DestinationDiskExists(path=instance_dir)

DestinationDiskExists: The supplied disk 

[Yahoo-eng-team] [Bug 1671385] [NEW] [live migration] The instance's task status is pending on migrating

[Dave Chen]

Public bug reported:

I am trying to migrate the instance to another compute node, but enter a wrong 
host name accidentally, after running the below commands,
$ nova live-migration 7ff75fa0-f88d-4bfd-8ef2-632e01f04bb9 $FAKE_HOST

Now the instance is pending on migration, and even cannot migration with
the *correct* destination host anymore, this is a bug I found in the N
stable release, but I believe the bug also exist in the O or master
branch.


The logs,

^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/objects/compute_node.py", line 503, 
in get_all_by_host
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00muse_slave=use_slave)
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/db/sqlalchemy/api.py", line 225, in 
wrapper
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mreturn f(*args, **kwargs)
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/objects/compute_node.py", line 498, 
in _db_compute_node_get_all_by_host
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mreturn db.compute_node_get_all_by_host(context, host)
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/db/api.py", line 278, in 
compute_node_get_all_by_host
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mreturn IMPL.compute_node_get_all_by_host(context, host)
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/db/sqlalchemy/api.py", line 270, in 
wrapped
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mreturn f(context, *args, **kwargs)
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/db/sqlalchemy/api.py", line 667, in 
compute_node_get_all_by_host
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mraise exception.ComputeHostNotFound(host=host)
^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mComputeHostNotFound: Compute host $fake could not be found.


change back to the correct hostname, now it says,
$ nova live-migration 6714b056-4950-4e63-83d3-fc383e977a53 openstack-dev
ERROR (Conflict): Cannot 'os-migrateLive' instance 
6714b056-4950-4e63-83d3-fc383e977a53 while it is in task_state migrating (HTTP 
409) (Request-ID: req-ed017800-37c0-4419-b533-3b52fba6b290)

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

Title:
  [live migration] The instance's task status is pending on migrating

Status in OpenStack Compute (nova):
  New

Bug description:
  I am trying to migrate the instance to another compute node, but enter a 
wrong host name accidentally, after running the below commands,
  $ nova live-migration 7ff75fa0-f88d-4bfd-8ef2-632e01f04bb9 $FAKE_HOST

  Now the instance is pending on migration, and even cannot migration
  with the *correct* destination host anymore, this is a bug I found in
  the N stable release, but I believe the bug also exist in the O or
  master branch.

  
  The logs,

  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/objects/compute_node.py", line 503, 
in get_all_by_host
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00muse_slave=use_slave)
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/db/sqlalchemy/api.py", line 225, in 
wrapper
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mreturn f(*args, **kwargs)
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/objects/compute_node.py", line 498, 
in _db_compute_node_get_all_by_host
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mreturn db.compute_node_get_all_by_host(context, host)
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/db/api.py", line 278, in 
compute_node_get_all_by_host
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00mreturn IMPL.compute_node_get_all_by_host(context, host)
  ^[[01;31m2017-03-09 03:12:03.541 TRACE nova.api.openstack.extensions 
^[[01;35m^[[00m  File "/opt/stack/nova/nova/db/sqlalchemy/api.py", line 270, in 
wrapped
  ^[[01;31m2017-03-09 03:12:03.541 TRACE 

[Yahoo-eng-team] [Bug 1643301] [NEW] bootstrapping keystone failed when LDAP backend is in use

[Dave Chen]

Public bug reported:

"keystone-manage bootstrap" command is coded for SQL backend, it's
should be okay if admin token is always supported by keystone, but we
have a plan to remove the support of admin token since it's expose a
security risk. And the patch to remove the support of write operation
for LDAP backend is on the fly.

Based on the above consideration, we should enable the bootrapping
keystone when using LDAP backend, but it currently not work sometimes,
for example.


# keystone-manage bootstrap --bootstrap-username Dave --bootstrap-password 
abc123 --bootstrap-project-name admin --bootstrap-role-name admin


2016-10-27 16:26:29.845 11359 TRACE keystone return 
self.result(msgid,all=1,timeout=self.timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 497, in result
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data, 
resp_msgid = self.result2(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 501, in 
result2
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data, 
resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 508, in 
result3
2016-10-27 16:26:29.845 11359 TRACE keystone 
resp_ctrl_classes=resp_ctrl_classes
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 515, in 
result4
2016-10-27 16:26:29.845 11359 TRACE keystone ldap_result = 
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in 
_ldap_call
2016-10-27 16:26:29.845 11359 TRACE keystone result = 
func(*args,**kwargs)
2016-10-27 16:26:29.845 11359 TRACE keystone UNDEFINED_TYPE: {'info': 
'enabled: attribute type undefined', 'desc': 'Undefined attribute type'}

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

Title:
  bootstrapping keystone failed when LDAP backend is in use

Status in OpenStack Identity (keystone):
  New

Bug description:
  "keystone-manage bootstrap" command is coded for SQL backend, it's
  should be okay if admin token is always supported by keystone, but we
  have a plan to remove the support of admin token since it's expose a
  security risk. And the patch to remove the support of write operation
  for LDAP backend is on the fly.

  Based on the above consideration, we should enable the bootrapping
  keystone when using LDAP backend, but it currently not work sometimes,
  for example.

  
  # keystone-manage bootstrap --bootstrap-username Dave --bootstrap-password 
abc123 --bootstrap-project-name admin --bootstrap-role-name admin


2016-10-27 16:26:29.845 11359 TRACE keystone return 
self.result(msgid,all=1,timeout=self.timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 497, in result
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data, 
resp_msgid = self.result2(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 501, in 
result2
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data, 
resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 508, in 
result3
2016-10-27 16:26:29.845 11359 TRACE keystone 
resp_ctrl_classes=resp_ctrl_classes
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 515, in 
result4
2016-10-27 16:26:29.845 11359 TRACE keystone ldap_result = 
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
2016-10-27 16:26:29.845 11359 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in 
_ldap_call
2016-10-27 16:26:29.845 11359 TRACE keystone result = 
func(*args,**kwargs)
2016-10-27 16:26:29.845 11359 TRACE keystone UNDEFINED_TYPE: {'info': 
'enabled: attribute type undefined', 'desc': 'Undefined attribute type'}

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

-- 
Mailing list: 

[Yahoo-eng-team] [Bug 1507456] Re: default setting of certificate for SAML signing doesn't work

[Dave Chen]

This is not an issue anymore with the latest code base, and the patch
intends to fix that has been abandoned, so mark it as won't fix.

** 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1507456

Title:
  default setting of certificate for SAML signing doesn't work

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

Bug description:
  Currently, the default setting is
  '/etc/keystone/ssl/certs/signing_cert.pem' which is the public key
  certificate which contains,

  - Signature Algorithm
  - Public Key
  - Signature Algorithm
  - Subject

  etc.

  But sigver.read_cert_from_file expects the certificate's content
  holds plain certificate information, which means it 's start from
  -BEGIN CERTIFICATE-
  or
  -BEGIN PUBLIC KEY-

  and end with

  -END CERTIFICATE-
  or
  -END PUBLIC KEY-

  So, the default setting will not work for SAML signing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1507456/+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 1622310] [NEW] trust still exist in the DB when the trustor/trustee/project is deleted

[Dave Chen]

Public bug reported:

When a trust is created, it requires trustee, trustor exist in the DB,
but when the associated user or project is deleted trust still exist in
DB.

The trust left in the DB is useless, and won't be used any longer since
either id of user/project is a random number when it got created it not
likely the trust will be effective in the future.

How to reproduce:
$ openstack user create trustor --password abc123
$ openstack user create trustee --password abc123
$ openstack project create trust_project
$ openstack role add 9cf8420ea5324f79b9d740e3ce5f0e04 --project 
2c455f8756d04b9485ec0b344c0e2089 --user 3e56ae62d1c94ead9fe9a4b31aaee070  (Add 
role service to project trust with user trustor)
curl -g -i -X POST -H "Accept: application/json" -H "X-Auth-Token: 
94d06939e65243f99cbfcf331bdf3e0b" -H "Content-Type: application/json" -d '{
"trust": {
"expires_at": "2017-02-27T18:30:59.99Z",
"impersonation": true,
"allow_redelegation": true,
"project_id": "2c455f8756d04b9485ec0b344c0e2089",
"roles": [
{
"name": "admin"
}
],
"trustee_user_id": "9147c64ef0624477bfc9dba818aa569c",
"trustor_user_id": "3e56ae62d1c94ead9fe9a4b31aaee070",
"redelegation_count": 3
}
}' http://10.239.159.68:5000/v3/OS-TRUST/trusts
$ openstack user delete trustor
$ openstack trust list
+---+---+---+---+---+---+
| ID| Expires At| Impersonation | 
Project ID| Trustee User ID   | Trustor User ID 
  |
+---+---+---+---+---+---+
| e7491ab063e247b6ad072b562 | 2017-02-27T18:30:59.0 | True  | 
2c455f8756d04b9485ec0b344 | 9147c64ef0624477bfc9dba81 | 
3e56ae62d1c94ead9fe9a4b31 |
| b32e37e   | 0Z|   | 
c0e2089   | 8aa569c   | aaee070 
  |
+---+---+---+---+---+---+

** Affects: keystone
 Importance: Undecided
 Status: New

** Description changed:

  When a trust is created, it requires trustee, trustor exist in the DB,
- but when the associated user or project is deleted trust still exist.
+ but when the associated user or project is deleted trust still exist in
+ DB.
  
  The trust left in the DB is useless, and won't be used any longer since
  either id of user/project is a random number when it got created it not
- likely the trust will be effective any longer.
- 
+ likely the trust will be effective in the future.
  
  How to reproduce:
  $ openstack user create trustor --password abc123
  $ openstack user create trustee --password abc123
  $ openstack project create trust_project
  $ openstack role add 9cf8420ea5324f79b9d740e3ce5f0e04 --project 
2c455f8756d04b9485ec0b344c0e2089 --user 3e56ae62d1c94ead9fe9a4b31aaee070  (Add 
role service to project trust with user trustor)
  curl -g -i -X POST -H "Accept: application/json" -H "X-Auth-Token: 
94d06939e65243f99cbfcf331bdf3e0b" -H "Content-Type: application/json" -d '{
- "trust": {
- "expires_at": "2017-02-27T18:30:59.99Z",
- "impersonation": true,
- "allow_redelegation": true,
- "project_id": "2c455f8756d04b9485ec0b344c0e2089",
- "roles": [
- {
- "name": "admin"
- }
- ],
- "trustee_user_id": "9147c64ef0624477bfc9dba818aa569c",
- "trustor_user_id": "3e56ae62d1c94ead9fe9a4b31aaee070",
- "redelegation_count": 3
- }
+ "trust": {
+ "expires_at": "2017-02-27T18:30:59.99Z",
+ "impersonation": true,
+ "allow_redelegation": true,
+ "project_id": "2c455f8756d04b9485ec0b344c0e2089",
+ "roles": [
+ {
+ "name": "admin"
+ }
+ ],
+ "trustee_user_id": "9147c64ef0624477bfc9dba818aa569c",
+ "trustor_user_id": "3e56ae62d1c94ead9fe9a4b31aaee070",
+ "redelegation_count": 3
+ }
  }' http://10.239.159.68:5000/v3/OS-TRUST/trusts
  $ openstack user delete trustor
  $ openstack trust list
  
+---+---+---+---+---+---+
  | ID| Expires At| Impersonation | 
Project ID| Trustee User ID   | Trustor User ID 
  |
  
+---+---+---+---+---+---+
  

[Yahoo-eng-team] [Bug 1620230] [NEW] migrate script is not correctly called in testcase

[Dave Chen]

Public bug reported:

Keystone has contract, migrate etc repo to support online rolling grade.
There is testcase test_start_version_db_init_version to make sure that
repos are called in the right sequence. But when it expects to call the
script from expand it calls the script from contact instead.

Here is simple debug message:

> /opt/stack/keystone/keystone/tests/unit/test_sql_upgrade.py(208)upgrade()
-> for ver, change in changeset:
(Pdb) n
> /opt/stack/keystone/keystone/tests/unit/test_sql_upgrade.py(209)upgrade()
-> self.schema_.runchange(ver, change, changeset.step)
(Pdb) p change

(Pdb) p change.__dict__
{'_module': ,
 'path': 
'/opt/stack/keystone/keystone/common/sql/expand_repo/versions/002_password_created_at_not_nullable.py'}

It shows the module that is acutally called is from contract_repo while
the path give us the correct info.

This could be found from here.
http://logs.openstack.org/91/364491/1/check/gate-keystone-python27-db-ubuntu-xenial/5d6e45e/console.html

** Affects: keystone
 Importance: Undecided
 Status: New

** Description changed:

  Keystone has contract, migrate etc repo to support online rolling grade.
  There is testcase test_start_version_db_init_version to make sure that
  repos are called in the right sequence. But when it expects to call the
  script from expand it calls the script from contact instead.
  
- Here is a simple debug message:
+ Here is simple debug message:
  
  > /opt/stack/keystone/keystone/tests/unit/test_sql_upgrade.py(208)upgrade()
  -> for ver, change in changeset:
  (Pdb) n
  > /opt/stack/keystone/keystone/tests/unit/test_sql_upgrade.py(209)upgrade()
  -> self.schema_.runchange(ver, change, changeset.step)
  (Pdb) p change
  
  (Pdb) p change.__dict__
  {'_module': ,
 'path': 
'/opt/stack/keystone/keystone/common/sql/expand_repo/versions/002_password_created_at_not_nullable.py'}
  
- 
- It shows the module that is acutally called in from contract_repo which the 
patch give us the correct info.
- 
+ It shows the module that is acutally called is from contract_repo while
+ the path give us the correct info.
  
  This could be found from here.
  
http://logs.openstack.org/91/364491/1/check/gate-keystone-python27-db-ubuntu-xenial/5d6e45e/console.html

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

Title:
  migrate script is not correctly called in testcase

Status in OpenStack Identity (keystone):
  New

Bug description:
  Keystone has contract, migrate etc repo to support online rolling
  grade. There is testcase test_start_version_db_init_version to make
  sure that repos are called in the right sequence. But when it expects
  to call the script from expand it calls the script from contact
  instead.

  Here is simple debug message:

  > /opt/stack/keystone/keystone/tests/unit/test_sql_upgrade.py(208)upgrade()
  -> for ver, change in changeset:
  (Pdb) n
  > /opt/stack/keystone/keystone/tests/unit/test_sql_upgrade.py(209)upgrade()
  -> self.schema_.runchange(ver, change, changeset.step)
  (Pdb) p change
  
  (Pdb) p change.__dict__
  {'_module': ,
 'path': 
'/opt/stack/keystone/keystone/common/sql/expand_repo/versions/002_password_created_at_not_nullable.py'}

  It shows the module that is acutally called is from contract_repo
  while the path give us the correct info.

  This could be found from here.
  
http://logs.openstack.org/91/364491/1/check/gate-keystone-python27-db-ubuntu-xenial/5d6e45e/console.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1620230/+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 1339855] Re: Raise NotImplementedError instead of NotImplemented

[Dave Chen]

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

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

** Changed in: keystone
 Assignee: (unassigned) => Ji.Wei (jiwei)

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

Title:
  Raise NotImplementedError instead of NotImplemented

Status in CloudCafe:
  Fix Committed
Status in Fuel for OpenStack:
  Fix Committed
Status in OpenStack Identity (keystone):
  New
Status in neutron:
  Fix Released
Status in Warm:
  New

Bug description:
  NotImplementedError is the name of the exception
  (https://docs.python.org/2/library/exceptions.html).

  NotImplemented is the name of a constant
  (https://docs.python.org/2/library/constants.html).

  It makes no sense to raise a constant. The exception should be raised
  instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloudcafe/+bug/1339855/+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 1616424] [NEW] Keystone OAuth1 doesn't handle invalid request properly

[Dave Chen]

Public bug reported:

For the access token request,


- If the signature is not valid, it will raise TypeError exception.

2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/common/wsgi.py", line 227, in __call__
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi result = 
method(req, **params)
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/controllers.py", line 309, in create_access_token
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi params = 
oauth1.extract_non_oauth_params(b)
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/core.py", line 108, in extract_non_oauth_params
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi return {k: v for k, 
v in params if not k.startswith('oauth_')}
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi TypeError: 'NoneType' 
object is not iterable
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi

- If the provided consumer does not exist, it will throw
NotImplementedError exception to show that dummy_client is not
implemented.

All these exception is not properly handled, end user doens't know
anything from these exception message. It should be Unauthorized
exception raised.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Description changed:

- For the access token request, if the signature is not valid, it will
- raise TypeError exception.
+ For the access token request,
+ 
+ 
+ - If the signature is not valid, it will raise TypeError exception.
  
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/common/wsgi.py", line 227, in __call__
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi result = 
method(req, **params)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/controllers.py", line 309, in create_access_token
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi params = 
oauth1.extract_non_oauth_params(b)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/core.py", line 108, in extract_non_oauth_params
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi return {k: v for 
k, v in params if not k.startswith('oauth_')}
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi TypeError: 'NoneType' 
object is not iterable
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi
  
+ - If the provided consumer does not exist, it will throw
+ NotImplementedError exception to show that dummy_client is not
+ implemented.
  
- If the provided consumer does not exist, it will throw NotImplementedError 
exception to show that dummy_client is not implemented.
- 
- 
- All these exception is not properly handled, end user doens't know anything 
from these exception message. It should be Unauthorized exception raised.
+ All these exception is not properly handled, end user doens't know
+ anything from these exception message. It should be Unauthorized
+ exception raised.

** Changed in: keystone
 Assignee: (unassigned) => Dave Chen (wei-d-chen)

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

Title:
  Keystone OAuth1 doesn't handle invalid request properly

Status in OpenStack Identity (keystone):
  New

Bug description:
  For the access token request,

  
  - If the signature is not valid, it will raise TypeError exception.

  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/common/wsgi.py", line 227, in __call__
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi result = 
method(req, **params)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/controllers.py", line 309, in create_access_token
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi params = 
oauth1.extract_non_oauth_params(b)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/core.py", line 108, in extract_non_oauth_params
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi return {k: v for 
k, v in params if not k.startswith('oauth_')}
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi TypeError: 'NoneType' 
object is not iterable
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi

  - If the provided consumer does not exist, it will throw
  NotImplementedError exception to show that dummy_client is not
  implemented.

  All these exception is not properly handled, end user doens't know
  anything from these exception message. It should be Unauthorized
  exception raised.

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

-- 
Mailing list: https://launc

[Yahoo-eng-team] [Bug 1615339] [NEW] The content type in OAuth1 extension is not spelled correclty

[Dave Chen]

Public bug reported:

Currently, the response's content type for creating request token or
access token is `application/x-www-urlformencoded`, there is no content
type named as this, the correct one should be `application/x-www-form-
urlencoded`.

** Affects: keystone
 Importance: Medium
 Assignee: Dave Chen (wei-d-chen)
 Status: Fix Committed

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

Title:
  The content type in OAuth1 extension is not spelled correclty

Status in OpenStack Identity (keystone):
  Fix Committed

Bug description:
  Currently, the response's content type for creating request token or
  access token is `application/x-www-urlformencoded`, there is no
  content type named as this, the correct one should be `application/x
  -www-form-urlencoded`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1615339/+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 1603905] [NEW] V2 API: enable a user doesn't work

[Dave Chen]

Public bug reported:

Enable user
===
PUT /v2.0/users/{userId}/OS-KSADM/enabled

The above API doesn't work, there are two issue here.

1. The API unnecessarily need a request body

url -g -i -X PUT
http://10.239.159.68/identity_v2_admin/v2.0/users/acc163d0efa14fe5b84e1dcc62ff6404
/OS-KSADM/enabled  -H "Content-Type: application/json" -H "Accept:
application/json" -H "X-Auth-Token:

{"error": {"message": "set_user_enabled() takes exactly 4 arguments (3
given)", "code": 400, "title": "Bad Request"}}

2. If we pass a request body without 'enabled' property, it cannot
enable the user.

openstack user show acc163d0efa14fe5b84e1dcc62ff6404
++--+
| Field  | Value|
++--+
| default_project_id | e9b5b0575cad498f8fce9e39ef209411 |
| domain_id  | default  |
| enabled| False|
| id | acc163d0efa14fe5b84e1dcc62ff6404 |
| name   | test_user|
++--+

curl -g -i -X PUT
http://10.239.159.68/identity_v2_admin/v2.0/users/acc163d0efa14fe5b84e1dcc62ff6404
/OS-KSADM/enabled  -H "Content-Type: application/json" -H "Accept:
application/json" -H "X-Auth-Token: e2fde9a73eb743e298e3d10aabebe5e0" -d
'{"user": {"name": "test_user"}}'

{"user": {"username": "test_user", "name": "test_user", "extra": {},
"enabled": false, "id": "acc163d0efa14fe5b84e1dcc62ff6404", "tenantId":
"e9b5b0575cad498f8fce9e39ef209411"}}

Nothing is changed, the user is still disabled.

** Affects: keystone
 Importance: Undecided
 Status: New

** Description changed:

  Enable user
  ===
  PUT /v2.0/users/{userId}/OS-KSADM/enabled
- 
  
  The above API doesn't work, there are two issue here.
  
  1. The API unnecessarily need a request body
  
  url -g -i -X PUT
  
http://10.239.159.68/identity_v2_admin/v2.0/users/acc163d0efa14fe5b84e1dcc62ff6404
  /OS-KSADM/enabled  -H "Content-Type: application/json" -H "Accept:
  application/json" -H "X-Auth-Token:
  
  {"error": {"message": "set_user_enabled() takes exactly 4 arguments (3
  given)", "code": 400, "title": "Bad Request"}}
  
- 
- 2. If we pass a request body without 'enabled' property, it could make the 
user enabled.
+ 2. If we pass a request body without 'enabled' property, it cannot
+ enable the user.
  
  openstack user show acc163d0efa14fe5b84e1dcc62ff6404
  ++--+
  | Field  | Value|
  ++--+
  | default_project_id | e9b5b0575cad498f8fce9e39ef209411 |
  | domain_id  | default  |
  | enabled| False|
  | id | acc163d0efa14fe5b84e1dcc62ff6404 |
  | name   | test_user|
  ++--+
  
- 
- curl -g -i -X PUT 
http://10.239.159.68/identity_v2_admin/v2.0/users/acc163d0efa14fe5b84e1dcc62ff6404/OS-KSADM/enabled
  -H "Content-Type: application/json" -H "Accept: application/json" -H 
"X-Auth-Token: 
+ curl -g -i -X PUT
+ 
http://10.239.159.68/identity_v2_admin/v2.0/users/acc163d0efa14fe5b84e1dcc62ff6404
+ /OS-KSADM/enabled  -H "Content-Type: application/json" -H "Accept:
+ application/json" -H "X-Auth-Token:
  
  {"user": {"username": "test_user", "name": "test_user", "extra": {},
  "enabled": false, "id": "acc163d0efa14fe5b84e1dcc62ff6404", "tenantId":
  "e9b5b0575cad498f8fce9e39ef209411"}}
  
- 
- Nothing changed, the user is still disabled.
+ Nothing is changed, the user is still disabled.

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

Title:
  V2 API: enable a user doesn't work

Status in OpenStack Identity (keystone):
  New

Bug description:
  Enable user
  ===
  PUT /v2.0/users/{userId}/OS-KSADM/enabled

  The above API doesn't work, there are two issue here.

  1. The API unnecessarily need a request body

  url -g -i -X PUT
  
http://10.239.159.68/identity_v2_admin/v2.0/users/acc163d0efa14fe5b84e1dcc62ff6404
  /OS-KSADM/enabled  -H "Content-Type: application/json" -H "Accept:
  application/json" -H "X-Auth-Token:

  {"error": {"message": "set_user_enabled() takes exactly 4 arguments (3
  given)", "code": 400, "title": "Bad Request"}}

  2. If we pass a request body without 'enabled' property, it cannot
  enable the user.

  openstack user show acc163d0efa14fe5b84e1dcc62ff6404
  ++--+
  | Field  | Value|
  ++--+
  | default_project_id | e9b5b0575cad498f8fce9e39ef209411 |
  | 

[Yahoo-eng-team] [Bug 1603861] [NEW] wrong check condtion for revoke event

[Dave Chen]

Public bug reported:

Keystone has the code to prevent `None` value to be returned when list
revoke event, but there is wrong check condition that leads to
access_token_i with None returned to end user.

see code here.
https://github.com/openstack/keystone/blob/master/keystone/models/revoke_model.py#L114-L115

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

Title:
  wrong check condtion for revoke event

Status in OpenStack Identity (keystone):
  New

Bug description:
  Keystone has the code to prevent `None` value to be returned when list
  revoke event, but there is wrong check condition that leads to
  access_token_i with None returned to end user.

  see code here.
  
https://github.com/openstack/keystone/blob/master/keystone/models/revoke_model.py#L114-L115

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1603861/+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 1598040] [NEW] return `revoked_at` for the revocation event

[Dave Chen]

Public bug reported:

Currently, the `revoked_at` is not returned when the API of getting
revocation events are executed, the `revoked_at` is always available in
the backends, get back this to the end user will help to give us the
clue on what happened and when the token was revoked, especially, if the
`issued_before` is set with a different time compared with `revoked_at`.

Steps to reproduce,
1. create a token.
2. delete the token.
3. list revoke events.

The sample output as follow,
{"events": [{"issued_before": "2016-06-27T06:12:52.00Z", "audit_id": 
"MwPMflshThm7zj7lGcWOnQ"}, {"issued_before": "2016-06-27T07:35:31.00Z", 
"audit_id": "nJpSKrzUQLq-jjygqvB-sA"}], "links": {"self": 
"http://10.239.159.68/identity/v3/OS-REVOKE/events;, "previous": null, "next": 
null}}

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

Title:
  return `revoked_at` for the revocation event

Status in OpenStack Identity (keystone):
  New

Bug description:
  Currently, the `revoked_at` is not returned when the API of getting
  revocation events are executed, the `revoked_at` is always available
  in the backends, get back this to the end user will help to give us
  the clue on what happened and when the token was revoked, especially,
  if the `issued_before` is set with a different time compared with
  `revoked_at`.

  Steps to reproduce,
  1. create a token.
  2. delete the token.
  3. list revoke events.

  The sample output as follow,
  {"events": [{"issued_before": "2016-06-27T06:12:52.00Z", "audit_id": 
"MwPMflshThm7zj7lGcWOnQ"}, {"issued_before": "2016-06-27T07:35:31.00Z", 
"audit_id": "nJpSKrzUQLq-jjygqvB-sA"}], "links": {"self": 
"http://10.239.159.68/identity/v3/OS-REVOKE/events;, "previous": null, "next": 
null}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1598040/+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 1597584] Re: error: Installed (but unpackaged) file(s) found: /usr/bin/keystone-all

[Dave Chen]

The spec file is not maintained in the upsteam code base, this looks
like an issue from your env or the bug from OSV.

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

Title:
  error: Installed (but unpackaged) file(s) found: /usr/bin/keystone-all

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  When using the Mitaka version of the source code to compile RPM
  keystone and keystoneclient package,the following error is reported as
  follows;

  keystone problem;
  RPM build errors:
  Installed (but unpackaged) file(s) found:
 /usr/bin/keystone-all

  keystoneclient problem;
  RPM build errors:
  Installed (but unpackaged) file(s) found:
 /usr/bin/keystone

  I found that in the spec file to add the following sentenc, the
  problem can be solved.So I think the default generated spec file
  should have the problem.

  openstack-keystone.spec;
  %{_bindir}/keystone-all

  openstack-keystoneclient.spec;
  %{_bindir}/keystone

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1597584/+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 1550110] Re: DB model is inconsistent with DB schema

[Dave Chen]

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

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

** 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1550110

Title:
  DB model is inconsistent with DB schema

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

Bug description:
  The user table created no longer consistent with the table model, this
  is beacuse the some fields were dropped after the shadow user patch
  (https://review.openstack.org/#/c/278570/) got merged but  table model
  is not updated accordingly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1550110/+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 1550110] [NEW] DB model is inconsistent with DB schema

[Dave Chen]

Public bug reported:

The user table created no longer consistent with the table model, this
is beacuse the some fields were dropped after the shadow user patch
(https://review.openstack.org/#/c/278570/) got merged but  table model
is not updated accordingly.

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

Title:
  DB model is inconsistent with DB schema

Status in OpenStack Identity (keystone):
  New

Bug description:
  The user table created no longer consistent with the table model, this
  is beacuse the some fields were dropped after the shadow user patch
  (https://review.openstack.org/#/c/278570/) got merged but  table model
  is not updated accordingly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1550110/+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 1549705] [NEW] migrate DB failed due to password cannot be null

[Dave Chen]

Public bug reported:

If there were user with null password existes,  keystone-manage db_sync
will fail when migrate the DB to
091_migrate_data_to_local_user_and_password_tables.py.

This is beacuse the `password` doesn't allow the the `password` to be
null.

The stacktrace is,

2016-02-25 16:48:02.187 16248 TRACE keystone _check_mysql_exception(errinfo)
2016-02-25 16:48:02.187 16248 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/err.py", line 112, in 
_check_mysql_exception
2016-02-25 16:48:02.187 16248 TRACE keystone raise errorclass(errno, 
errorvalue)
2016-02-25 16:48:02.187 16248 TRACE keystone DBError: 
(pymysql.err.IntegrityError) (1048, u"Column 'password' cannot be null") [SQL: 
u'INSERT INTO password (local_user_id, password) VALUES (%(local_user_id_0)s, 
%(password_0)s), (%(local_user_id_1)s, %(password_1)s), (%(local_user_id_2)s, 
%(password_2)s), (%(local_user_id_3)s, %(password_3)s), (%(local_user_id_4)s, 
%(password_4)s), (%(local_user_id_5)s, %(password_5)s), (%(local_user_id_6)s, 
%(password_6)s)'] [parameters: {u'local_user_id_5': 6, u'local_user_id_2': 3, 
u'password_0': 
u'$6$rounds=1$9MsHCDa99KIsGgyl$ElIyqo1w.SvcmM2cg3Lml6snJ.5txHxlq63Pmu19bxpnAkvqndenOV9t0Nu0qTCoxawGCpj2pUjfxuV0fDBz4.',
 u'password_1': 
u'$6$rounds=1$VBqe3vSR7zxy10GE$jRIqQtJQkfkRJWmzKVViChVn7NHstzcC5mJANnl7bpzQaluqz.33Q6BG5MGHyFu.hWRRz3jxoLjsgTvv2GOpa0',
 u'password_2': 
u'$6$rounds=1$LtmUoF9GZAdPfLDo$pQ313zPsbtjB7NM7bR73Jg8V7bO2oM5LysJsi2wkjCk7nwSwoos9QJdvbVL.9rV8u/3MdcDgRY1Eu28EtahQ41',
 u'password_3': u'$6$rounds=1$rjTuGfpVeLXm608/$VjjU8ShY
 
DZT6PFKjqZvf0zUvg5P7IUlW1K1ZN6NfH2a/0hGbVkcaDqky/z7fujdRfMifKjtthpLnLCN0cPPnp1',
 u'password_4': 
u'$6$rounds=1$KYR89pU.OwWJ9MdD$cMwW970ccn44gTISz2P9vZ3lD14zvQC6R4O7q0yLunNVcqH09RMV4o7Vr47MnkejpWKvnxYKntxrmYSmlm/yg/',
 u'password_5': 
u'$6$rounds=1$i6WcGIGqDtNML2lX$7jSzlulHQXW2mbvYfniYvlJ.EmRjM2JxYqCaldhLVgKrULImg2Gj0ZqAmoq2xs9CgXcu5jJH1L9pCMxF4gMfM.',
 u'password_6': None, u'local_user_id_4': 5, u'local_user_id_1': 2, 
u'local_user_id_0': 1, u'local_user_id_6': 7, u'local_user_id_3': 4}]

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Description changed:

  If there were user with null password existes,  keystone-manage db_sync
  will fail when migrate the DB to
  091_migrate_data_to_local_user_and_password_tables.py.
  
- This is beacuse the `password` not allow the the `password` to be null.
- 
+ This is beacuse the `password` doesn't allow the the `password` to be
+ null.
  
  The stacktrace is,
  
  2016-02-25 16:48:02.187 16248 TRACE keystone 
_check_mysql_exception(errinfo)
  2016-02-25 16:48:02.187 16248 TRACE keystone   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/err.py", line 112, in 
_check_mysql_exception
  2016-02-25 16:48:02.187 16248 TRACE keystone raise errorclass(errno, 
errorvalue)
  2016-02-25 16:48:02.187 16248 TRACE keystone DBError: 
(pymysql.err.IntegrityError) (1048, u"Column 'password' cannot be null") [SQL: 
u'INSERT INTO password (local_user_id, password) VALUES (%(local_user_id_0)s, 
%(password_0)s), (%(local_user_id_1)s, %(password_1)s), (%(local_user_id_2)s, 
%(password_2)s), (%(local_user_id_3)s, %(password_3)s), (%(local_user_id_4)s, 
%(password_4)s), (%(local_user_id_5)s, %(password_5)s), (%(local_user_id_6)s, 
%(password_6)s)'] [parameters: {u'local_user_id_5': 6, u'local_user_id_2': 3, 
u'password_0': 
u'$6$rounds=1$9MsHCDa99KIsGgyl$ElIyqo1w.SvcmM2cg3Lml6snJ.5txHxlq63Pmu19bxpnAkvqndenOV9t0Nu0qTCoxawGCpj2pUjfxuV0fDBz4.',
 u'password_1': 
u'$6$rounds=1$VBqe3vSR7zxy10GE$jRIqQtJQkfkRJWmzKVViChVn7NHstzcC5mJANnl7bpzQaluqz.33Q6BG5MGHyFu.hWRRz3jxoLjsgTvv2GOpa0',
 u'password_2': 
u'$6$rounds=1$LtmUoF9GZAdPfLDo$pQ313zPsbtjB7NM7bR73Jg8V7bO2oM5LysJsi2wkjCk7nwSwoos9QJdvbVL.9rV8u/3MdcDgRY1Eu28EtahQ41',
 u'password_3': u'$6$rounds=1$rjTuGfpVeLXm608/$VjjU8S
 
hYDZT6PFKjqZvf0zUvg5P7IUlW1K1ZN6NfH2a/0hGbVkcaDqky/z7fujdRfMifKjtthpLnLCN0cPPnp1',
 u'password_4': 
u'$6$rounds=1$KYR89pU.OwWJ9MdD$cMwW970ccn44gTISz2P9vZ3lD14zvQC6R4O7q0yLunNVcqH09RMV4o7Vr47MnkejpWKvnxYKntxrmYSmlm/yg/',
 u'password_5': 
u'$6$rounds=1$i6WcGIGqDtNML2lX$7jSzlulHQXW2mbvYfniYvlJ.EmRjM2JxYqCaldhLVgKrULImg2Gj0ZqAmoq2xs9CgXcu5jJH1L9pCMxF4gMfM.',
 u'password_6': None, u'local_user_id_4': 5, u'local_user_id_1': 2, 
u'local_user_id_0': 1, u'local_user_id_6': 7, u'local_user_id_3': 4}]

** Changed in: keystone
 Assignee: (unassigned) => Dave Chen (wei-d-chen)

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

Title:
  migrate DB failed due to password cannot be null

Status in OpenStack Identity (keystone):
  New

Bug description:
  If there were user with null password existes,  keystone-manage
  db_sync will fail when migrate the DB to
  091_migrat

[Yahoo-eng-team] [Bug 1429566] Re: misused region / region_id in EP

[Dave Chen]

per the comments in that patch, no bother to fix this.

** 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1429566

Title:
  misused region / region_id in EP

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

Bug description:
  Checked from the current IMPL in EP, 'region_id' has the same meaning with 
'region', and region with the context actaully means 'region_id'.
  
https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L333
  endpoint['region'] = endpoint['region_id']

  But, region and region_id is not used in a consistent way, for example,
  Table definition,  region_id is used,
  
https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L76

  Upgrade or downgrade scripts, region is used,
  
https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/042_endpoint_enabled.py#L126

  EP in the catalog when using SQL as the backend, both region and region_id 
are presented in the catalog, this seems is not necessary.
  
https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L333

  while using the template as the backend, only region is presented in the 
catalog,
  
https://github.com/openstack/keystone/blob/master/keystone/catalog/core.py#L487

  some code cleanup will help to give a consistent way to use region or
  region_id.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1429566/+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 1429576] Re: region field in 'new_endpoint_ref' is never effective.

[Dave Chen]

Since the code base for those testcases have been updated dramatically,
the issue is not applied to current code base. So mark it won't fix.

** 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1429576

Title:
  region field in 'new_endpoint_ref' is never effective.

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

Bug description:
  we use 'region' instead of 'region_id' in EP refer for testing.
  
https://github.com/openstack/keystone/blob/f6c01dd1673b290578e9fff063e27104412ffeda/keystone/tests/unit/test_catalog.py#L158

  But we are trying to get region_id from the reference data, so this field and 
any tests depend on region_id shall never take effective.
  
https://github.com/openstack/keystone/blob/f6c01dd1673b290578e9fff063e27104412ffeda/keystone/catalog/backends/sql.py#L317

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1429576/+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 1541218] [NEW] fail lots of V2 testcases due to no `policy.json` could be found

[Dave Chen]

Public bug reported:

How to reproduce:

1. remove the `/etc/keystone/policy.json` if there is since this file
only exists after env is setup, this will make sure the test engine to
search the `policy.json` in the code base, for example,  load the policy
file from here `/opt/stack/keystone/etc/policy.json`

2. run the v2 testcases separately,
$ python -m unittest keystone.tests.unit.test_v2

or simply run only one testcases.
$ python -m unittest 
keystone.tests.unit.test_credential.TestCredentialEc2.test_ec2_list_credentials

3. You will hit the following exceptions.

enforce identity:validate_token: {'is_delegated_auth': False, 
'access_token_id': None, 'user_id': u'180af26c59e9460f81652569d27fc439', 
'roles': ['Service'], 'user_domain_id': 'default', 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'project_id': 'service', 'trust_id': None, 
'project_domain_id': 'default'}
Failed to find some config files: policy.json
Traceback (most recent call last):
  File "keystone/common/wsgi.py", line 247, 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 "keystone/common/controller.py", line 179, in inner
utils.flatten_dict(policy_dict))
  File "keystone/policy/backends/rules.py", line 77, in enforce
enforce(credentials, action, target)
  File "keystone/policy/backends/rules.py", line 69, in enforce
return _ENFORCER.enforce(action, target, credentials, **extra)
  File "/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py", line 
540, in enforce
self.load_rules()
  File "/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py", line 
443, in load_rules
self.policy_path = self._get_policy_path(self.policy_file)
  File "/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py", line 
513, in _get_policy_path
raise cfg.ConfigFilesNotFoundError((path,))
ConfigFilesNotFoundError: Failed to find some config files: policy.json
}}}

Traceback (most recent call last):
  File "keystone/tests/unit/test_v2.py", line 186, in 
test_validate_token_service_role
token=token)
  File "keystone/tests/unit/rest.py", line 208, in admin_request
return self._request(app=self.admin_app, **kwargs)
  File "keystone/tests/unit/rest.py", line 197, in _request
response = self.restful_request(**kwargs)
  File "keystone/tests/unit/rest.py", line 182, in restful_request
**kwargs)
  File "keystone/tests/unit/rest.py", line 90, in request
**kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webtest/app.py", line 567, in 
request
expect_errors=expect_errors,
  File "/usr/local/lib/python2.7/dist-packages/webtest/app.py", line 632, in 
do_request
self._check_status(status, res)
  File "/usr/local/lib/python2.7/dist-packages/webtest/app.py", line 664, in 
_check_status
res)
webtest.app.AppError: Bad response: 500 Internal Server Error (not 200 OK or 
3xx redirect for http://localhost/v2.0/tokens/3c69de14762f42ac89852eb1f3c7eab5)
'{"error": {"message": "An unexpected error prevented the server from 
fulfilling your request.", "code": 500, "title": "Internal Server Error"}}'

Ran 122 tests in 18.954s

FAILED (errors=73, skipped=3)

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Description changed:

  How to reproduce:
  
  1. remove the `/etc/keystone/policy.json` if there is since this file
  only exists after env is setup, this will make sure the test engine to
- search the `policy.json` in the code base, for example,  load this
- policy file. `/opt/stack/keystone/etc/policy.json`
+ search the `policy.json` in the code base, for example,  load the policy
+ file from here `/opt/stack/keystone/etc/policy.json`
  
- 2. run the v2 testcases seperately, 
+ 2. run the v2 testcases separately,
  $ python -m unittest keystone.tests.unit.test_v2
  
  or simply run only one testcases.
  $ python -m unittest keystone.tests.unit.test_credential.TestCredentialEc2
  
  3. You will hit the following exceptions.
  
  enforce identity:validate_token: {'is_delegated_auth': False, 
'access_token_id': None, 'user_id': u'180af26c59e9460f81652569d27fc439', 
'roles': ['Service'], 'user_domain_id': 'default', 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'project_id': 'service', 'trust_id': None, 
'project_domain_id': 'default'}
  Failed to find some config files: policy.json
  Traceback (most recent call last):
-   File "keystone/common/wsgi.py", line 247, in __call__
- result = method(context, **params)
-   File "/usr/local/lib/python2.7/dist-packages/oslo_log/versionutils.py", 
line 165, in wrapped
-

[Yahoo-eng-team] [Bug 1534140] [NEW] keystone-manage bootstrap should not create user/project if it fails

[Dave Chen]

Public bug reported:

If `keystone-manage bootstrap` fails with the role already exists (this
may happen if someone use OSC CLI created a role but someone else want
to boostrap a set of `user`, `project` or `role` without aware of  the
role has already created.), the project or user can still be created
successfully.

And then if redefine the role, `keystone-manage bootstrap` will still
fail since `user`, `project` have been created, but `keystone-manage
bootstrap` cannot handle with this.

See the example:
dave@shldeOTCopen005:~$ keystone-manage bootstrap --bootstrap-username 
bootstrap_user --bootstrap-project-name bootstrap_project --bootstrap-role-name 
admin --bootstrap-password abc123
25784 TRACE keystone details=_('Duplicate Entry'))
25784 TRACE keystone Conflict: Conflict occurred attempting to store role - 
Duplicate Entry
25784 TRACE keystone


change the role to `bootstrap_role` ...

dave@shldeOTCopen005:~$ keystone-manage bootstrap --bootstrap-username 
bootstrap_user --bootstrap-project-name bootstrap_project --bootstrap-role-name 
bootstrap_role --bootstrap-password abc123
25813 TRACE keystone details=_('Duplicate Entry'))
25813 TRACE keystone Conflict: Conflict occurred attempting to store project - 
Duplicate Entry
25813 TRACE keystone

So, if we want to boostrap again, we need delete project, user manually,  this 
is not friendly to end  user.
`keystone-manage bootstrap` should not create any `user`, `project` if the 
command is not executed successfully.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Dave Chen (wei-d-chen)

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

Title:
  keystone-manage bootstrap should not create user/project if it fails

Status in OpenStack Identity (keystone):
  New

Bug description:
  If `keystone-manage bootstrap` fails with the role already exists
  (this may happen if someone use OSC CLI created a role but someone
  else want to boostrap a set of `user`, `project` or `role` without
  aware of  the role has already created.), the project or user can
  still be created successfully.

  And then if redefine the role, `keystone-manage bootstrap` will still
  fail since `user`, `project` have been created, but `keystone-manage
  bootstrap` cannot handle with this.

  See the example:
  dave@shldeOTCopen005:~$ keystone-manage bootstrap --bootstrap-username 
bootstrap_user --bootstrap-project-name bootstrap_project --bootstrap-role-name 
admin --bootstrap-password abc123
  25784 TRACE keystone details=_('Duplicate Entry'))
  25784 TRACE keystone Conflict: Conflict occurred attempting to store role - 
Duplicate Entry
  25784 TRACE keystone

  
  change the role to `bootstrap_role` ...

  dave@shldeOTCopen005:~$ keystone-manage bootstrap --bootstrap-username 
bootstrap_user --bootstrap-project-name bootstrap_project --bootstrap-role-name 
bootstrap_role --bootstrap-password abc123
  25813 TRACE keystone details=_('Duplicate Entry'))
  25813 TRACE keystone Conflict: Conflict occurred attempting to store project 
- Duplicate Entry
  25813 TRACE keystone

  So, if we want to boostrap again, we need delete project, user manually,  
this is not friendly to end  user.
  `keystone-manage bootstrap` should not create any `user`, `project` if the 
command is not executed successfully.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1534140/+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 1528981] [NEW] keystone fernet cannot work with mod wsgi anymore

[Dave Chen]

Public bug reported:

With the latest code, fernet cannot work anymore due to this change id
(Change-Id: I0723cd50bbb464c38c9efcf1888e39d14950997b).

The stacktrace like this,

2015-12-23 10:47:53.526487 9923 DEBUG passlib.registry 
[req-e4501bef-5f1e-4bd3-8e1b-7320093b767b - - - - -] registered 'sha512_crypt' 
handler:  
register_crypt_handler 
/usr/local/lib/python2.7/dist-packages/passlib/registry.py:284
2015-12-23 10:47:53.625320 9923 INFO keystone.token.providers.fernet.utils 
[req-e4501bef-5f1e-4bd3-8e1b-7320093b767b - - - - -] Loaded 2 encryption keys 
(max_active_keys=3) from: /etc/keystone/fernet-keys/
2015-12-23 10:47:53.735808 mod_wsgi (pid=9923): Exception occurred processing 
WSGI script '/usr/local/bin/keystone-wsgi-public'.
2015-12-23 10:47:53.735856 TypeError: expected byte string object for header 
value, value of type unicode found


Need identity which change from this commit 
(https://review.openstack.org/#/c/259563/) cause the regression

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Dave Chen (wei-d-chen)

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

Title:
  keystone fernet cannot work with mod wsgi anymore

Status in OpenStack Identity (keystone):
  New

Bug description:
  With the latest code, fernet cannot work anymore due to this change id
  (Change-Id: I0723cd50bbb464c38c9efcf1888e39d14950997b).

  The stacktrace like this,

  2015-12-23 10:47:53.526487 9923 DEBUG passlib.registry 
[req-e4501bef-5f1e-4bd3-8e1b-7320093b767b - - - - -] registered 'sha512_crypt' 
handler:  
register_crypt_handler 
/usr/local/lib/python2.7/dist-packages/passlib/registry.py:284
  2015-12-23 10:47:53.625320 9923 INFO keystone.token.providers.fernet.utils 
[req-e4501bef-5f1e-4bd3-8e1b-7320093b767b - - - - -] Loaded 2 encryption keys 
(max_active_keys=3) from: /etc/keystone/fernet-keys/
  2015-12-23 10:47:53.735808 mod_wsgi (pid=9923): Exception occurred processing 
WSGI script '/usr/local/bin/keystone-wsgi-public'.
  2015-12-23 10:47:53.735856 TypeError: expected byte string object for header 
value, value of type unicode found

  
  Need identity which change from this commit 
(https://review.openstack.org/#/c/259563/) cause the regression

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1528981/+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 1525317] Re: IdP doesn't support field based DB filtering

[Dave Chen]

** Project changed: python-openstackclient => 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/1525317

Title:
  IdP doesn't support field based DB filtering

Status in OpenStack Identity (keystone):
  New

Bug description:
  Currently, IdP doesn't support to filter the DB records based on the
  field,  for example,

  If configure the DB like this,
  mysql> select * from identity_provider;
  +--+-+-+
  | id   | enabled | description |
  +--+-+-+
  | idp1 |   1 | NULL|
  | idp2 |   1 | NULL|
  +--+-+-+
  2 rows in set (0.00 sec)

  And I query the IdP by this curl, I get all of the records from DB,

  curl -g -i -X GET http://127.0.0.1:35357/v3/OS-
  FEDERATION/identity_providers?id=idontexist -H "User-Agent: python-
  keystoneclient" -H "Accept: application/json" -H "X-Auth-Token:
  f74ac35177cb4720891a9cfed5ea1b9c"

  {
   "links": {
    "self": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers?id=idp1;,
    "previous": null,
    "next": null
   },
   "identity_providers": [{
    "remote_ids": [],
    "enabled": true,
    "id": "idp1",
    "links": {
     "self": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1;,
     "protocols": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1/protocols;
    },
    "description": null
   }, {
    "remote_ids": [],
    "enabled": true,
    "id": "idp2",
    "links": {
     "self": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2;,
     "protocols": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2/protocols;
    },
    "description": null
   }]
  }

  This feature should be supported since OSC depends on this to filter
  the DB records wanted.

  Noted: Open this bug since it's different with
  https://bugs.launchpad.net/python-openstackclient/+bug/1479837, they
  are two different things, and I think this more sound like a feature
  that keystone should support.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1525317/+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 1489059] Re: "db type could not be determined" running py34

[Dave Chen]

** Also affects: keystoneauth
   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/1489059

Title:
  "db type could not be determined" running py34

Status in Aodh:
  In Progress
Status in cloudkitty:
  Fix Committed
Status in glance_store:
  In Progress
Status in heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-lib:
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in keystonemiddleware:
  In Progress
Status in Manila:
  In Progress
Status in neutron:
  Fix Committed
Status in python-keystoneclient:
  In Progress
Status in Sahara:
  Fix Committed
Status in senlin:
  Fix Committed
Status in tempest:
  In Progress

Bug description:
  When running tox for the first time, the py34 execution fails with an
  error saying "db type could not be determined".

  This issue is know to be caused when the run of py27 preceeds py34 and
  can be solved erasing the .testrepository and running "tox -e py34"
  first of all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1489059/+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 1489059] Re: "db type could not be determined" running py34

[Dave Chen]

** Also affects: keystonemiddleware
   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/1489059

Title:
  "db type could not be determined" running py34

Status in Aodh:
  In Progress
Status in cloudkitty:
  Fix Committed
Status in glance_store:
  In Progress
Status in heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-lib:
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in keystonemiddleware:
  In Progress
Status in Manila:
  In Progress
Status in neutron:
  Fix Committed
Status in python-keystoneclient:
  In Progress
Status in Sahara:
  Fix Committed
Status in senlin:
  Fix Committed
Status in tempest:
  In Progress

Bug description:
  When running tox for the first time, the py34 execution fails with an
  error saying "db type could not be determined".

  This issue is know to be caused when the run of py27 preceeds py34 and
  can be solved erasing the .testrepository and running "tox -e py34"
  first of all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1489059/+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 1489059] Re: "db type could not be determined" running py34

[Dave Chen]

** Also affects: python-keystoneclient
   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/1489059

Title:
  "db type could not be determined" running py34

Status in Aodh:
  In Progress
Status in cloudkitty:
  Fix Committed
Status in glance_store:
  In Progress
Status in heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-lib:
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystonemiddleware:
  In Progress
Status in Manila:
  In Progress
Status in neutron:
  Fix Committed
Status in python-keystoneclient:
  In Progress
Status in Sahara:
  Fix Committed
Status in senlin:
  Fix Committed
Status in tempest:
  In Progress

Bug description:
  When running tox for the first time, the py34 execution fails with an
  error saying "db type could not be determined".

  This issue is know to be caused when the run of py27 preceeds py34 and
  can be solved erasing the .testrepository and running "tox -e py34"
  first of all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1489059/+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 1520850] [NEW] testcase fail due to value is not match

[Dave Chen]

Public bug reported:

The testcase fail occasionally, since the value got from DB or cache is not 
always match with the sequence of when the value is created.
 

  File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
435, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 'db0c40558d7e4125a3f68b3b8bfb9720' != 
u'526844a9f6f747ffaa422ce48795fbc5'

** Affects: keystone
 Importance: Undecided
 Status: New

** Changed in: python-openstackclient
   Status: New => Invalid

** Project changed: python-openstackclient => keystone

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

Title:
  testcase fail due to value is not match

Status in OpenStack Identity (keystone):
  New

Bug description:
  The testcase fail occasionally, since the value got from DB or cache is not 
always match with the sequence of when the value is created.
   

File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
435, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: 'db0c40558d7e4125a3f68b3b8bfb9720' != 
u'526844a9f6f747ffaa422ce48795fbc5'

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1520850/+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 1516468] [NEW] miss the testcase for caching to get_catalog/get_v3_catalog in endpoint filter extension

[Dave Chen]

Public bug reported:

With the patch [1] got merged, keystone has the ablity to cache
catalog/v3 catalog, and will invalidate the cache when there is any
changes about the catalog, i.e. add_endpoint_to_project,
remove_endpoint_from_project. But the testcase was missed there, this
means there is no testcase covered in keystone even the API in the
Manager layer was not defined correctly [2].

The bug will focus on `add_endpoint_to_project` and 
`remove_endpoint_from_project` and leave `add_endpoint_group_to_project`
and `remove_endpoint_group_from_project` as it is, this is beacuse these two 
API should impact the endpoints in theory but it's not in practice.  So, add 
some testcase to test its impact on catalog is impossible. There should be 
anothor bug filed and testcase will be added when that bug was fixed.

[1] https://review.openstack.org/#/c/215212/
[2] https://review.openstack.org/#/c/243951/

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Description changed:

  With the patch [1] got merged, keystone has the ablity to cache
  catalog/v3 catalog, and will invalidate the cache when there is any
  changes about the catalog, i.e. add_endpoint_to_project,
  remove_endpoint_from_project. But the testcase was missed there, this
  means there is no testcase covered in keystone even the API in the
  Manager layer was not defined correctly [2].
  
- 
  The bug will focus on `add_endpoint_to_project` and 
`remove_endpoint_from_project` and leave `add_endpoint_group_to_project`
- and `remove_endpoint_group_from_project` as it is, this is beacuse these two 
should be impact the endpoints but in theory but it's not in practice.  So, add 
some testcase to test it impact catalog is impossible. There should be anthor 
bug filed and will add the testcase when that bug was fixed.
+ and `remove_endpoint_group_from_project` as it is, this is beacuse these two 
API should impact the endpoints in theory but it's not in practice.  So, add 
some testcase to test its impact on catalog is impossible. There should be 
anothor bug filed and testcase will be added when that bug was fixed.
  
  [1] https://review.openstack.org/#/c/215212/
  [2] https://review.openstack.org/#/c/243951/

** Changed in: keystone
 Assignee: (unassigned) => Dave Chen (wei-d-chen)

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

Title:
  miss the testcase for caching to get_catalog/get_v3_catalog in
  endpoint filter extension

Status in OpenStack Identity (keystone):
  New

Bug description:
  With the patch [1] got merged, keystone has the ablity to cache
  catalog/v3 catalog, and will invalidate the cache when there is any
  changes about the catalog, i.e. add_endpoint_to_project,
  remove_endpoint_from_project. But the testcase was missed there, this
  means there is no testcase covered in keystone even the API in the
  Manager layer was not defined correctly [2].

  The bug will focus on `add_endpoint_to_project` and 
`remove_endpoint_from_project` and leave `add_endpoint_group_to_project`
  and `remove_endpoint_group_from_project` as it is, this is beacuse these two 
API should impact the endpoints in theory but it's not in practice.  So, add 
some testcase to test its impact on catalog is impossible. There should be 
anothor bug filed and testcase will be added when that bug was fixed.

  [1] https://review.openstack.org/#/c/215212/
  [2] https://review.openstack.org/#/c/243951/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1516468/+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 1516469] [NEW] endpoints not show correctly when using "endpoint_filter.sql" as catalog's backend driver

[Dave Chen]

terface": "admin",
"service_id": "8bb4bdc9fcac4fb5bec4f6779268f0d0",
"id": "151b9f8b132f4c26a562872e09389a69"
},
{
"region_id": "RegionOne",
"links": {
"self": 
"http://10.239.48.36:5000/v3/endpoints/bff53486b72c44e9b00cf69184b66ce9;
},
"url": "http://10.239.48.36:;,
"region": "RegionOne",
"enabled": true,
"interface": "admin",
"service_id": "69da5bbf65aa4565b9833655075e7a8a",
"id": "bff53486b72c44e9b00cf69184b66ce9"
},
{
"region_id": "RegionOne",
"links": {
"self": 
"http://10.239.48.36:5000/v3/endpoints/d0ee548da623477eb73b60018c3e5ab8;
},
"url": "http://10.239.48.36:8776/v1/$(tenant_id)s",
"region": "RegionOne",
"enabled": true,
"interface": "admin",
"service_id": "928eb1b536464e238e573284760e656a",
"id": "d0ee548da623477eb73b60018c3e5ab8"
},
{
"region_id": "RegionOne",
"links": {
"self": 
"http://10.239.48.36:5000/v3/endpoints/44699ffc64274612a0c039531f66096d;
},
"url": "http://10.239.48.36:8776/v2/$(tenant_id)s",
"region": "RegionOne",
"enabled": true,
"interface": "admin",
"service_id": "ab4b7001ccaa4c3896407d4523466183",
"id": "44699ffc64274612a0c039531f66096d"
}
],
"links": {
"self": 
"http://10.239.48.36:5000/v3/OS-EP-FILTER/projects/927e252fb44d4b5cac9d4fb24d85be41/endpoints;,
"previous": null,
"next": null
}
}
...

- Get a project scoped token

$ curl -i   -H "Content-Type: application/json"   -d '{ "auth": {
"identity": {
  "methods": ["password"],
  "password": {
"user": {
  "name": "admin",
  "domain": { "id": "default" },
  "password": "12345"
}
  }
},
"scope": {
  "project": {
"name": "admin",
"domain": { "id": "default" }
  }
}
  }
}'   http://10.239.48.36:5000/v3/auth/tokens; echo

...
"catalog": [
{
"endpoints": [
{
"region_id": null,
"url": "http://127.0.0.0:20;,
"interface": "internal",
"id": "5be3023ddf984fcf942b2a396eb0167b"
}
],
"type": "s3",
"id": "69da5bbf65aa4565b9833655075e7a8a"
}
],
...

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Description changed:

  If the endpoint group project association was created, and
  "endpoint_filter.sql" as catalog's backend driver. All of the endpoints
  associated with the project and match the criterion defined in the
  "endpoint group" should be given after a project scoped token was
  return.
  
  But currently, those endpoints can *only* be show if using call
  `list_endpoints_for_project` API explictly but cannot get back when the
  project scoped token was issued.
- 
  
  Steps to reproduce this issue.
  
  -Create endpoint group.
  
  $curl -g -i -X POST http://10.239.48.36:5000/v3/OS-EP-
  FILTER/endpoint_groups -H "X-Auth-
  Token:a85e07129aa54f61a46395543a3146af" -H "Content-Type:
  application/json" -d '{"endpoint_group": {"description": "endpoint group
  description", "filters": {"interface": "admin"}, "name":
  "endpoint_group_name"}}'
  
- 
- - Create endpoint_group project  association
+ - Create endpoint_group project association
  
  $curl -g -i -X PUT http://10.239.48.36:5000/v3/OS-EP-
  
FILTER/endpoint_groups/ea1af6e153bf4b87a88b5962de8cdae8/projects/927e252fb44d4b5cac9d4fb24d85be41
  -H "X-Auth-Token:a85e07129aa54f61a46395543a3146af" -H &

[Yahoo-eng-team] [Bug 1507456] [NEW] default setting of certificate for SAML signing doesn't work

[Dave Chen]

Public bug reported:

Currently, the default setting is
'/etc/keystone/ssl/certs/signing_cert.pem' which is the public key
certificate which contains,

- Signature Algorithm
- Public Key
- Signature Algorithm
- Subject

etc.

But sigver.read_cert_from_file expects the certificate's content
holds plain certificate information, which means it 's start from
-BEGIN CERTIFICATE-
or
-BEGIN PUBLIC KEY-

and end with

-END CERTIFICATE-
or
-END PUBLIC KEY-

So, the default setting will not work for SAML signing.

** Affects: keystone
 Importance: Undecided
 Status: New

** Description changed:

  Currently, the default setting is
  '/etc/keystone/ssl/certs/signing_cert.pem' which is the public key
  certificate which contains,
  
  - Signature Algorithm
  - Public Key
  - Signature Algorithm
  - Subject
  
+ etc.
+ 
  But sigver.read_cert_from_file expects the certificate's content
- holds plain certificate information, which means it 's start from 
+ holds plain certificate information, which means it 's start from
  -BEGIN CERTIFICATE-
  or
  -BEGIN PUBLIC KEY-
  
  and end with
  
  -END CERTIFICATE-
  or
- -END PUBLIC KEY- 
+ -END PUBLIC KEY-
  
  So, the default setting will not work for SAML signing.

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

Title:
  default setting of certificate for SAML signing doesn't work

Status in Keystone:
  New

Bug description:
  Currently, the default setting is
  '/etc/keystone/ssl/certs/signing_cert.pem' which is the public key
  certificate which contains,

  - Signature Algorithm
  - Public Key
  - Signature Algorithm
  - Subject

  etc.

  But sigver.read_cert_from_file expects the certificate's content
  holds plain certificate information, which means it 's start from
  -BEGIN CERTIFICATE-
  or
  -BEGIN PUBLIC KEY-

  and end with

  -END CERTIFICATE-
  or
  -END PUBLIC KEY-

  So, the default setting will not work for SAML signing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1507456/+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 1505972] [NEW] endpoint policy's resource_relation is not built corretly

[Dave Chen]

Public bug reported:

Since endpoint_policy has been moved into keystone core, so should
update the resource relation to build the correct url accordingly.

see:
https://github.com/openstack/keystone/blob/master/keystone/endpoint_policy/routers.py

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 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/1505972

Title:
  endpoint policy's resource_relation is not built corretly

Status in Keystone:
  In Progress

Bug description:
  Since endpoint_policy has been moved into keystone core, so should
  update the resource relation to build the correct url accordingly.

  see:
  
https://github.com/openstack/keystone/blob/master/keystone/endpoint_policy/routers.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1505972/+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 1505972] Re: endpoint policy's resource_relation is not built corretly

[Dave Chen]

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

Title:
  endpoint policy's resource_relation is not built corretly

Status in Keystone:
  Invalid

Bug description:
  Since endpoint_policy has been moved into keystone core, so should
  update the resource relation to build the correct url accordingly.

  see:
  
https://github.com/openstack/keystone/blob/master/keystone/endpoint_policy/routers.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1505972/+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 1487663] [NEW] no testcases to cover the region creation with invalid id

[Dave Chen]

Public bug reported:

Regions use ID differently. The user can specify the ID or it will be
generated automatically. Region schema validation require the Region ID
is string type, but there is no testcase to cover this.

CURL
=
- create region,
curl -g -i -X POST http://127.0.0.1:35357/v3/regions -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: 
9b7866d88de2408381549e9af55b0c07 -d '{region: {enabled: true, id: 1234}}'

{error: {message: Invalid input for field 'id'. The value is
'1234'., code: 400, title: Bad Request}}

- create endpoint,
curl -g -i -X POST http://127.0.0.1:35357/v3/endpoints -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: 
af9a74ea521045b2880e2a364a16b05a -d '{endpoint: {url: 192.168.1.1:78, 
interface: public, region: 7891, enabled: true, service_id: 
ce08ac9579fc4de78d0ee17efeca530e}}'

{error: {message: Invalid input for field 'region'. The value is
'7891'., code: 400, title: Bad Request}}

** Affects: keystone
 Importance: Undecided
 Status: New

** Description changed:

  Regions use ID differently. The user can specify the ID or it will be
  generated automatically. Region schema validation require the Region ID
  is string type, but there is no testcase to cover this.
  
- 
- CURL 
- ===
- create region,
+ CURL
+ =
+ - create region,
  curl -g -i -X POST http://127.0.0.1:35357/v3/regions -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: 
9b7866d88de2408381549e9af55b0c07 -d '{region: {enabled: true, id: 1234}}'
  
  {error: {message: Invalid input for field 'id'. The value is
  '1234'., code: 400, title: Bad Request}}
  
- 
- create endpoint,
+ - create endpoint,
  curl -g -i -X POST http://127.0.0.1:35357/v3/endpoints -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: 
af9a74ea521045b2880e2a364a16b05a -d '{endpoint: {url: 192.168.1.1:78, 
interface: public, region: 7891, enabled: true, service_id: 
ce08ac9579fc4de78d0ee17efeca530e}}'
  
- 
- {error: {message: Invalid input for field 'region'. The value is 
'7891'., code: 400, title: Bad Request}}
+ {error: {message: Invalid input for field 'region'. The value is
+ '7891'., code: 400, title: Bad Request}}

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

Title:
  no testcases to cover the region creation with invalid id

Status in Keystone:
  New

Bug description:
  Regions use ID differently. The user can specify the ID or it will be
  generated automatically. Region schema validation require the Region
  ID is string type, but there is no testcase to cover this.

  CURL
  =
  - create region,
  curl -g -i -X POST http://127.0.0.1:35357/v3/regions -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: 
9b7866d88de2408381549e9af55b0c07 -d '{region: {enabled: true, id: 1234}}'

  {error: {message: Invalid input for field 'id'. The value is
  '1234'., code: 400, title: Bad Request}}

  - create endpoint,
  curl -g -i -X POST http://127.0.0.1:35357/v3/endpoints -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: 
af9a74ea521045b2880e2a364a16b05a -d '{endpoint: {url: 192.168.1.1:78, 
interface: public, region: 7891, enabled: true, service_id: 
ce08ac9579fc4de78d0ee17efeca530e}}'

  {error: {message: Invalid input for field 'region'. The value is
  '7891'., code: 400, title: Bad Request}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1487663/+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 1480119] [NEW] Replace tearDown with addCleanup in unit tests

[Dave Chen]

Public bug reported:

tearDown should be replace by addCleanup  in the unit tests to avoid
stale state if setUp fails or any failure in tearDown method.

There is a bp in cinder project, just copy them here for reference,
Infra team has indicated that tearDown methods should be replaced with 
addCleanup in unit tests.
The reason is that all addCleanup methods will be executed even if one of them 
fails, while a failure in tearDown method can leave the rest of the tearDown 
un-executed, which can leave stale state laying around.

Moreover, tearDown methods won't run if an exception raises in setUp
method, while addCleanup will run in such case.

So, we should replace tearDown with addCleanup methods.

Since there tearDown method is not used widely in keystone sub-project,
so just file a bug to track the change.


The link of the reference: 
https://blueprints.launchpad.net/cinder/+spec/replace-teardown-with-addcleanup

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

** Description changed:

  tearDown should be replace by addCleanup  in the unit tests to avoid
  stale state if setUp fails or any failure in tearDown method.
  
  There is a bp in cinder project, just copy them here for reference,
  Infra team has indicated that tearDown methods should be replaced with 
addCleanup in unit tests.
  The reason is that all addCleanup methods will be executed even if one of 
them fails, while a failure in tearDown method can leave the rest of the 
tearDown un-executed, which can leave stale state laying around.
  
  Moreover, tearDown methods won't run if an exception raises in setUp
  method, while addCleanup will run in such case.
  
  So, we should replace tearDown with addCleanup methods.
  
+ Since there tearDown method is not used widely in keystone sub-project,
+ so just file a bug to track the change.
  
- Since there tearDown method is not used widely in keystone sub-project, so 
just file a bug to track the change.
+ 
+ The link of the reference: 
https://blueprints.launchpad.net/cinder/+spec/replace-teardown-with-addcleanup

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

Title:
  Replace tearDown with addCleanup in unit tests

Status in Keystone:
  In Progress

Bug description:
  tearDown should be replace by addCleanup  in the unit tests to avoid
  stale state if setUp fails or any failure in tearDown method.

  There is a bp in cinder project, just copy them here for reference,
  Infra team has indicated that tearDown methods should be replaced with 
addCleanup in unit tests.
  The reason is that all addCleanup methods will be executed even if one of 
them fails, while a failure in tearDown method can leave the rest of the 
tearDown un-executed, which can leave stale state laying around.

  Moreover, tearDown methods won't run if an exception raises in setUp
  method, while addCleanup will run in such case.

  So, we should replace tearDown with addCleanup methods.

  Since there tearDown method is not used widely in keystone sub-
  project, so just file a bug to track the change.

  
  The link of the reference: 
https://blueprints.launchpad.net/cinder/+spec/replace-teardown-with-addcleanup

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1480119/+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 1402187] Re: Invalid token provider

[Dave Chen]

stevedore is landing

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

Title:
  Invalid token provider

Status in Keystone:
  Won't Fix

Bug description:
  When specify token provoider as pkiz instead of full class path of
  token provider as keystone.token.providers.[pkiz|pki|uuid].Provider
  in keystone.conf I will get the following exception thrown in the log
  file.

  2014-12-14 04:48:18.710721 Traceback (most recent call last):
  2014-12-14 04:48:18.710732   File /var/www/keystone/main, line 53, in 
module
  2014-12-14 04:48:18.710798 drivers = backends.load_backends()
  2014-12-14 04:48:18.710817   File /opt/stack/keystone/keystone/backends.py, 
line 48, in load_backends
  2014-12-14 04:48:18.710851 token_provider_api=token.provider.Manager())
  2014-12-14 04:48:18.710867   File 
/opt/stack/keystone/keystone/common/dependency.py, line 200, in wrapper
  2014-12-14 04:48:18.710944 self.__wrapped_init__(*args, **kwargs)
  2014-12-14 04:48:18.710950   File 
/opt/stack/keystone/keystone/common/dependency.py, line 110, in 
__wrapped_init__
  2014-12-14 04:48:18.710969 init(self, *args, **kwargs)
  2014-12-14 04:48:18.710974   File 
/opt/stack/keystone/keystone/token/provider.py, line 152, in __init__
  2014-12-14 04:48:18.711100 super(Manager, 
self).__init__(self.get_token_provider())
  2014-12-14 04:48:18.711106   File 
/opt/stack/keystone/keystone/common/manager.py, line 70, in __init__
  2014-12-14 04:48:18.711150 self.driver = 
importutils.import_object(driver_name)
  2014-12-14 04:48:18.711165   File 
/usr/local/lib/python2.7/dist-packages/oslo/utils/importutils.py, line 38, in 
import_object
  2014-12-14 04:48:18.711226 return import_class(import_str)(*args, 
**kwargs)
  2014-12-14 04:48:18.711244   File 
/usr/local/lib/python2.7/dist-packages/oslo/utils/importutils.py, line 27, in 
import_class
  2014-12-14 04:48:18.711252 __import__(mod_str)
  2014-12-14 04:48:18.711264 ValueError: Empty module name

  I understand the comment in keystone.conf has show us how to config
  the provider but in my opinion, it should also support pkiz|pki|uuid
  besides the full class path, or at least, there should be one
  dedicated exception to show us what's wrong with the config. Seen from
  the code there is no invalid provider checking, so invalid token
  provider exception to show us what's wrong with the config is desired.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1402187/+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 1473848] [NEW] create_region_with_id miss the schema validation

[Dave Chen]

Public bug reported:

When I am debugging the code for the proposed fixing of bug #1468597,
#1466872 [1], I found some testcases failure, they are
`test_create_region_with_duplicate_id`,
`test_create_region_with_matching_ids` and `test_create_region_with_id`.

After digging into the code, I found when the region is created with id
provided is not given schema validation at all, this is beasue  region
reference data is not passed as dict, see [2], but validator expect the
reference data is in kwargs [3] which is common usage when it's resource
is request with restful API.

So, the region creation with id given missed the schema validation.


[1] https://review.openstack.org/#/c/195903/
[2] 
https://github.com/openstack/keystone/blob/master/keystone/catalog/controllers.py#L173
[3] 
https://github.com/openstack/keystone/blob/master/keystone/common/validation/__init__.py#L34-L35

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

Title:
  create_region_with_id miss the schema validation

Status in Keystone:
  New

Bug description:
  When I am debugging the code for the proposed fixing of bug #1468597,
  #1466872 [1], I found some testcases failure, they are
  `test_create_region_with_duplicate_id`,
  `test_create_region_with_matching_ids` and
  `test_create_region_with_id`.

  After digging into the code, I found when the region is created with
  id provided is not given schema validation at all, this is beasue
  region reference data is not passed as dict, see [2], but validator
  expect the reference data is in kwargs [3] which is common usage when
  it's resource is request with restful API.

  So, the region creation with id given missed the schema validation.


  [1] https://review.openstack.org/#/c/195903/
  [2] 
https://github.com/openstack/keystone/blob/master/keystone/catalog/controllers.py#L173
  [3] 
https://github.com/openstack/keystone/blob/master/keystone/common/validation/__init__.py#L34-L35

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1473848/+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 1472987] [NEW] helpless exception message

[Dave Chen]

Public bug reported:

When there is an invalid token in use,  keystone will throw
exception.UnsupportedTokenVersionException, but currently, there is no
useful information provided and user don't know what's happened, see the
following error message.


CLI,
/usr/local/lib/python2.7/dist-packages/keystoneclient/shell.py:64: 
DeprecationWarning: The keystone CLI is deprecated in favor of 
python-openstackclient. For a Python library, continue using 
python-keystoneclient.
  'python-keystoneclient.', DeprecationWarning)
An unexpected error prevented the server from fulfilling your request:  
(Disable debug mode to suppress these details.) (HTTP 500) (Request-ID: 
req-b116d6e4-336a-48d0-9a00-939249ac5b1a)

keystone.log,
2015-07-09 17:19:27.034038 14283 ERROR keystone.common.wsgi [-]
2015-07-09 17:19:27.034047 14283 TRACE keystone.common.wsgi Traceback (most 
recent call last):
2015-07-09 17:19:27.034049 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/common/wsgi.py, line 463, in __call__
2015-07-09 17:19:27.034051 14283 TRACE keystone.common.wsgi response = 
self.process_request(request)
2015-07-09 17:19:27.034053 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/middleware/core.py, line 209, in process_request
2015-07-09 17:19:27.034055 14283 TRACE keystone.common.wsgi auth_context = 
self._build_auth_context(request)
2015-07-09 17:19:27.034057 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/middleware/core.py, line 189, in 
_build_auth_context
2015-07-09 17:19:27.034059 14283 TRACE keystone.common.wsgi 
token_data=self.token_provider_api.validate_token(token_id))
2015-07-09 17:19:27.034061 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/models/token_model.py, line 59, in __init__
2015-07-09 17:19:27.034063 14283 TRACE keystone.common.wsgi raise 
exception.UnsupportedTokenVersionException()
2015-07-09 17:19:27.034065 14283 TRACE keystone.common.wsgi 
UnsupportedTokenVersionException
2015-07-09 17:19:27.034067 14283 TRACE keystone.common.wsgi


We can provide some unformation to end user, so the user knows what's happened 
and going to fix it.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 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/1472987

Title:
  helpless exception message

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  When there is an invalid token in use,  keystone will throw
  exception.UnsupportedTokenVersionException, but currently, there is no
  useful information provided and user don't know what's happened, see
  the following error message.

  
  CLI,
  /usr/local/lib/python2.7/dist-packages/keystoneclient/shell.py:64: 
DeprecationWarning: The keystone CLI is deprecated in favor of 
python-openstackclient. For a Python library, continue using 
python-keystoneclient.
'python-keystoneclient.', DeprecationWarning)
  An unexpected error prevented the server from fulfilling your request:  
(Disable debug mode to suppress these details.) (HTTP 500) (Request-ID: 
req-b116d6e4-336a-48d0-9a00-939249ac5b1a)

  keystone.log,
  2015-07-09 17:19:27.034038 14283 ERROR keystone.common.wsgi [-]
  2015-07-09 17:19:27.034047 14283 TRACE keystone.common.wsgi Traceback (most 
recent call last):
  2015-07-09 17:19:27.034049 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/common/wsgi.py, line 463, in __call__
  2015-07-09 17:19:27.034051 14283 TRACE keystone.common.wsgi response = 
self.process_request(request)
  2015-07-09 17:19:27.034053 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/middleware/core.py, line 209, in process_request
  2015-07-09 17:19:27.034055 14283 TRACE keystone.common.wsgi auth_context 
= self._build_auth_context(request)
  2015-07-09 17:19:27.034057 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/middleware/core.py, line 189, in 
_build_auth_context
  2015-07-09 17:19:27.034059 14283 TRACE keystone.common.wsgi 
token_data=self.token_provider_api.validate_token(token_id))
  2015-07-09 17:19:27.034061 14283 TRACE keystone.common.wsgi   File 
/opt/stack/keystone/keystone/models/token_model.py, line 59, in __init__
  2015-07-09 17:19:27.034063 14283 TRACE keystone.common.wsgi raise 
exception.UnsupportedTokenVersionException()
  2015-07-09 17:19:27.034065 14283 TRACE keystone.common.wsgi 
UnsupportedTokenVersionException
  2015-07-09 17:19:27.034067 14283 TRACE keystone.common.wsgi

  
  We can provide some unformation to end user, so the user knows what's 
happened and going to fix it.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net

[Yahoo-eng-team] [Bug 1471671] [NEW] testcase didn't use the reference data correctly

[Dave Chen]

Public bug reported:

'test_create_project_invalid_domain_id' intends to test create project with 
invalid domain id, but it didn't use the invalid reference data but use a empty 
request body.
see: 
https://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/test_v3_assignment.py#n612

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

Title:
  testcase didn't use the reference data correctly

Status in OpenStack Identity (Keystone):
  New

Bug description:
  'test_create_project_invalid_domain_id' intends to test create project with 
invalid domain id, but it didn't use the invalid reference data but use a empty 
request body.
  see: 
https://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/test_v3_assignment.py#n612

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1471671/+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 1471385] [NEW] group creation without domain using admin_token should fail nicer

[Dave Chen]

Public bug reported:

see bug: https://bugs.launchpad.net/keystone/+bug/1434000, the same
issue could also happen when creating a 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/1471385

Title:
  group creation without domain using admin_token should fail nicer

Status in OpenStack Identity (Keystone):
  New

Bug description:
  see bug: https://bugs.launchpad.net/keystone/+bug/1434000, the same
  issue could also happen when creating a group.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1471385/+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 1468597] [NEW] v3 - Ambiguous error when no request body is provided

[Dave Chen]

Public bug reported:

This bug is basically the same issue as the bug described here: 
https://bugs.launchpad.net/keystone/+bug/1466872.
But this bug is expected to be a blanket bug as there are many entities/API 
have the same issue. Instead of filed a lot of bugs in the lp,let's take this 
as a blanket.

Example:
dave@openstack-dev:~$ curl -g -i -X POST http://localhost:35357/v3/services -H 
Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: 3ec87e90d60c4a318acf7b2bc6e55300
HTTP/1.1 400 Bad Request
Date: Thu, 25 Jun 2015 03:37:52 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
x-openstack-request-id: req-70c66170-271c-4e69-b5e6-67fa9ff91f59
Content-Length: 115
Content-Type: application/json
Via: 1.1 shzintpr02.sh.intel.com
Proxy-Connection: Keep-Alive
Connection: Keep-Alive

{error: {message: create_service() takes exactly 3 arguments (2
given), code: 400, title: Bad Request}}

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

** Description changed:

- This bug is basically the same issue as the bug descriped here: 
https://bugs.launchpad.net/keystone/+bug/1466872.
+ This bug is basically the same issue as the bug described here: 
https://bugs.launchpad.net/keystone/+bug/1466872.
  But this bug is expected to be a blanket bug as there are many entities/API 
has the same issue.
  
  example:
  dave@openstack-dev:~$ curl -g -i -X POST http://localhost:35357/v3/services 
-H Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: 3ec87e90d60c4a318acf7b2bc6e55300
  HTTP/1.1 400 Bad Request
  Date: Thu, 25 Jun 2015 03:37:52 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Vary: X-Auth-Token
  x-openstack-request-id: req-70c66170-271c-4e69-b5e6-67fa9ff91f59
  Content-Length: 115
  Content-Type: application/json
  Via: 1.1 shzintpr02.sh.intel.com
  Proxy-Connection: Keep-Alive
  Connection: Keep-Alive
  
  {error: {message: create_service() takes exactly 3 arguments (2
  given), code: 400, title: Bad Request}}

** Description changed:

  This bug is basically the same issue as the bug described here: 
https://bugs.launchpad.net/keystone/+bug/1466872.
- But this bug is expected to be a blanket bug as there are many entities/API 
has the same issue.
+ But this bug is expected to be a blanket bug as there are many entities/API 
have the same issue. Instead of filed a lot of bugs in the lp,let's take this 
as a blanket.
  
  example:
  dave@openstack-dev:~$ curl -g -i -X POST http://localhost:35357/v3/services 
-H Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: 3ec87e90d60c4a318acf7b2bc6e55300
  HTTP/1.1 400 Bad Request
  Date: Thu, 25 Jun 2015 03:37:52 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Vary: X-Auth-Token
  x-openstack-request-id: req-70c66170-271c-4e69-b5e6-67fa9ff91f59
  Content-Length: 115
  Content-Type: application/json
  Via: 1.1 shzintpr02.sh.intel.com
  Proxy-Connection: Keep-Alive
  Connection: Keep-Alive
  
  {error: {message: create_service() takes exactly 3 arguments (2
  given), code: 400, title: Bad Request}}

** Description changed:

  This bug is basically the same issue as the bug described here: 
https://bugs.launchpad.net/keystone/+bug/1466872.
  But this bug is expected to be a blanket bug as there are many entities/API 
have the same issue. Instead of filed a lot of bugs in the lp,let's take this 
as a blanket.
  
- example:
+ Example:
  dave@openstack-dev:~$ curl -g -i -X POST http://localhost:35357/v3/services 
-H Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: 3ec87e90d60c4a318acf7b2bc6e55300
  HTTP/1.1 400 Bad Request
  Date: Thu, 25 Jun 2015 03:37:52 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Vary: X-Auth-Token
  x-openstack-request-id: req-70c66170-271c-4e69-b5e6-67fa9ff91f59
  Content-Length: 115
  Content-Type: application/json
  Via: 1.1 shzintpr02.sh.intel.com
  Proxy-Connection: Keep-Alive
  Connection: Keep-Alive
  
  {error: {message: create_service() takes exactly 3 arguments (2
  given), code: 400, title: Bad Request}}

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

Title:
  v3 - Ambiguous error when no request body is provided

Status in OpenStack Identity (Keystone):
  New

Bug description:
  This bug is basically the same issue as the bug described here: 
https://bugs.launchpad.net/keystone/+bug/1466872.
  But this bug is expected to be a blanket bug as there are many entities/API 
have the same issue. Instead of filed a lot of bugs in the lp,let's take this 
as a blanket.

  Example:
  dave@openstack-dev:~$ curl -g -i -X POST http://localhost:35357/v3/services 
-H Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: 3ec87e90d60c4a318acf7b2bc6e55300
  HTTP/1.1 400 Bad Request
  Date: Thu, 25 Jun 2015 03:37

[Yahoo-eng-team] [Bug 1466116] [NEW] With using V3 cloud admin policy, domain admin cannot issue a token for the project in his domain

[Dave Chen]

Public bug reported:

With v3 cloud admin policy file, use can be assigned to admin role in a
specific domain, and there would be multiple projects in that domain,
the user should have full access to this domain, but when we tried to
issue a token scoped to the project in that domain we will get some
exception as follow:

$ openstack token issue
ERROR: openstack User 072afe1ba1154d089b3c7a0952ba188b has no access to project 
e221bf92b65e435a9ef665f7aa681528 (Disable debug mode to suppress these 
details.) (HTTP 401) (Request-ID: req-4db81144-d0bf-4edb-9027-5bfb106ed160)

Here is configuration in my env.

user name is cloud_admin
mysql select id, name from user where id = '072afe1ba1154d089b3c7a0952ba188b';
+--+-+
| id   | name|
+--+-+
| 072afe1ba1154d089b3c7a0952ba188b | cloud_admin |
+--+-+

user cloud_admin has the admin role in the domain `admin_domain`
mysql select role.name, assignment.target_id from role, assignment where 
assignment.actor_id = '072afe1ba1154d089b3c7a0952ba188b' and assignment.role_id 
= role.id;
+---+--+
| name  | target_id|
+---+--+
| admin | b792bb2101254aaebd11694cc99c89be |
+---+--+

mysql select * from domain where id = 'b792bb2101254aaebd11694cc99c89be';
+--+--+-+---+
| id   | name | enabled | extra |
+--+--+-+---+
| b792bb2101254aaebd11694cc99c89be | admin_domain |   1 | {}|
+--+--+-+---+
1 row in set (0.00 sec)


project: e221bf92b65e435a9ef665f7aa681528 (admin_project) is associated with 
the admin_domain.
mysql select project.id as project_id, project.name as project_name, 
domain.name as domain_name from project, domain where project.id = 
'e221bf92b65e435a9ef665f7aa681528' and project.domain_id = domain.id;
+--+---+--+
| project_id   | project_name  | domain_name  |
+--+---+--+
| e221bf92b65e435a9ef665f7aa681528 | admin_project | admin_domain |
+--+---+--+

This may be somehow duplicated with this bug:
https://bugs.launchpad.net/keystone/+bug/1437407, some experts in this
area can help to triage or confirm it.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  With using V3 cloud admin policy, domain admin cannot issue a token
  for the project in his domain

Status in OpenStack Identity (Keystone):
  New

Bug description:
  With v3 cloud admin policy file, use can be assigned to admin role in
  a specific domain, and there would be multiple projects in that
  domain, the user should have full access to this domain, but when we
  tried to issue a token scoped to the project in that domain we will
  get some exception as follow:

  $ openstack token issue
  ERROR: openstack User 072afe1ba1154d089b3c7a0952ba188b has no access to 
project e221bf92b65e435a9ef665f7aa681528 (Disable debug mode to suppress these 
details.) (HTTP 401) (Request-ID: req-4db81144-d0bf-4edb-9027-5bfb106ed160)

  Here is configuration in my env.

  user name is cloud_admin
  mysql select id, name from user where id = 
'072afe1ba1154d089b3c7a0952ba188b';
  +--+-+
  | id   | name|
  +--+-+
  | 072afe1ba1154d089b3c7a0952ba188b | cloud_admin |
  +--+-+

  user cloud_admin has the admin role in the domain `admin_domain`
  mysql select role.name, assignment.target_id from role, assignment where 
assignment.actor_id = '072afe1ba1154d089b3c7a0952ba188b' and assignment.role_id 
= role.id;
  +---+--+
  | name  | target_id|
  +---+--+
  | admin | b792bb2101254aaebd11694cc99c89be |
  +---+--+

  mysql select * from domain where id = 'b792bb2101254aaebd11694cc99c89be';
  +--+--+-+---+
  | id   | name | enabled | extra |
  +--+--+-+---+
  | b792bb2101254aaebd11694cc99c89be

[Yahoo-eng-team] [Bug 1464874] Re: no enough info on how to create V3 credentials

[Dave Chen]

@Steve, checked it. thanks! There is already a manul on how to create ec2 
credentials with the V3 API. 
URL: http://developer.openstack.org/api-ref-identity-v3.html#createCredential, 
so close the impact on the keystone.

As to the change in OSC, just thought we should provide some hint on how
to create in the hint message.


** Changed in: keystone
   Status: New = Invalid

** No longer affects: keystone

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

Title:
  no enough info on how to create V3 credentials

Status in OpenStack Command Line Client:
  In Progress

Bug description:
  There is no enough info on how to create ec2 type V3 credentials,
  OpenStack CLI help message just show that we need positional arguments
  user and blob, but no idea what the blob looks like. Since there is a
  hard requirement that blob should be a json string and the input must
  includes access attribute if the credential is ec2 credential, we
  should provide more info on how to create V3 credentails.

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-openstackclient/+bug/1464874/+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 1464874] Re: no enough info on how to create V3 credentials

[Dave Chen]

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

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

** Description changed:

  There is no enough info on how to create ec2 type V3 credentials,
  OpenStack CLI help message just show that this we need positional
  arguments user and blob, but no idea what the blob looks like. Since
  there is a hard requirement that blob should be a json string and the
  input must includes access attribute, we should provide more info on how
  to create V3 credentails.
  
- And we aslo need some document somewhere in keystone side, how to create
- the ec2 type V3 credentials by the CLI, what's the valid input, and what
- the curl command looks like etc.
+ And we aslo need document somewhere in keystone side, how to create the
+ ec2 type V3 credentials by the CLI, what's the valid input, and what the
+ curl command looks like etc.

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

Title:
  no enough info on how to create V3 credentials

Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Command Line Client:
  In Progress

Bug description:
  There is no enough info on how to create ec2 type V3 credentials,
  OpenStack CLI help message just show that this we need positional
  arguments user and blob, but no idea what the blob looks like. Since
  there is a hard requirement that blob should be a json string and the
  input must includes access attribute, we should provide more info on
  how to create V3 credentails.

  And we aslo need document somewhere in keystone side, how to create
  the ec2 type V3 credentials by the CLI, what's the valid input, and
  what the curl command looks like etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1464874/+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 1463727] [NEW] unicode is not string

[Dave Chen]

Public bug reported:

In the testcase of test_v3_token_data_helper_populate_audit_info_string
[1], we generate audit_info via base64.urlsafe_b64encode, the value
returned is a string, acutally, the audit_info should be unicode instead
of a string type.

This will hide some issues while the testcase should detect [2] instead
of simply pass the test.


[1] 
https://github.com/openstack/keystone/blob/master/keystone/tests/unit/token/test_token_data_helper.py#L31
[2] 
https://review.openstack.org/#/c/125410/11/keystone/token/providers/common.py

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  unicode is not string

Status in OpenStack Identity (Keystone):
  New

Bug description:
  In the testcase of
  test_v3_token_data_helper_populate_audit_info_string [1], we generate
  audit_info via base64.urlsafe_b64encode, the value returned is a
  string, acutally, the audit_info should be unicode instead of a string
  type.

  This will hide some issues while the testcase should detect [2]
  instead of simply pass the test.


  [1] 
https://github.com/openstack/keystone/blob/master/keystone/tests/unit/token/test_token_data_helper.py#L31
  [2] 
https://review.openstack.org/#/c/125410/11/keystone/token/providers/common.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1463727/+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

[Dave Chen]

As the comments in this patch:
(https://review.openstack.org/#/c/133135/), we won't fix this this time.

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

Title:
  Join multiple criteria together

Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in OpenStack Identity (Keystone):
  Won't Fix

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/glance/+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 1459532] [NEW] api_curl_examples.rst is out of date

[Dave Chen]

Public bug reported:

Two example in the `api_curl_examples.rst` is not accurate anymore, we
need to update the docs.

1. Default scope - Get an token with default scope (may be unscoped)
Since this example is trying to get an unscoped token, so there will be no 
catalog associated with the token, so the response is not correct.


2. Getting a token from a token
The example here is also trying to get a unscoped token from a existing token, 
so there will no catalog associated with the token, so the response is not 
correct.

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

Title:
  api_curl_examples.rst is out of date

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Two example in the `api_curl_examples.rst` is not accurate anymore, we
  need to update the docs.

  1. Default scope - Get an token with default scope (may be unscoped)
  Since this example is trying to get an unscoped token, so there will be no 
catalog associated with the token, so the response is not correct.

  
  2. Getting a token from a token
  The example here is also trying to get a unscoped token from a existing 
token, so there will no catalog associated with the token, so the response is 
not correct.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1459532/+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 1459116] [NEW] miss testcase for the external authentication of DefaultDomain

[Dave Chen]

Public bug reported:

As to the external authentication methods, the classes defined includ 
'KerberosDomain', 'Domain' and 'DefaultDomain', the *DefaultDomain* is acutally 
different with 'KerberosDomain' and  'Domain', they are different use cases.
We have testcases for 'KerberosDomain' and 'Domain', but there is no testcase 
to verify 'DefaultDomain', so we need to fix up.


[1] 
https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/external.py#L66

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

Title:
  miss testcase for the external authentication of DefaultDomain

Status in OpenStack Identity (Keystone):
  New

Bug description:
  As to the external authentication methods, the classes defined includ 
'KerberosDomain', 'Domain' and 'DefaultDomain', the *DefaultDomain* is acutally 
different with 'KerberosDomain' and  'Domain', they are different use cases.
  We have testcases for 'KerberosDomain' and 'Domain', but there is no testcase 
to verify 'DefaultDomain', so we need to fix up.

  
  [1] 
https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/external.py#L66

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1459116/+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 1454968] [NEW] hard to understand the uri printed in the log

[Dave Chen]

Public bug reported:

In keystone's log file, we can easily find some uri printed like this:
http://127.0.0.1:35357/v3/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens

seems there is something wrong when we are trying to log the uri in the log 
file.
LOG.info('%(req_method)s %(uri)s', {
'req_method': req.environ['REQUEST_METHOD'].upper(),
'uri': wsgiref.util.request_uri(req.environ),
})


code is here: 
https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L232, 
but seems it has already been wrong when the req is passed in.

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

Title:
  hard to understand the uri printed in the log

Status in OpenStack Identity (Keystone):
  New

Bug description:
  In keystone's log file, we can easily find some uri printed like this:
  
http://127.0.0.1:35357/v3/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens

  seems there is something wrong when we are trying to log the uri in the log 
file.
  LOG.info('%(req_method)s %(uri)s', {
  'req_method': req.environ['REQUEST_METHOD'].upper(),
  'uri': wsgiref.util.request_uri(req.environ),
  })

  
  code is here: 
https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L232, 
but seems it has already been wrong when the req is passed in.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1454968/+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] [NEW] Join multiple criteria together

[Dave Chen]

Public bug reported:

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.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

-- 
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):
  New

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.

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 1447472] [NEW] versionutils.deprecated is used to mark callables as deprecated

[Dave Chen]

Public bug reported:

https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L420
~ #L423 intends to use versionutils.deprecated to deprecate the passing
of `extras`, this is not the valid case versionutils.deprecated could be
implied.

see:
https://github.com/openstack/keystone/blob/master/keystone/openstack/common/versionutils.py#L165
for where `versionutils.deprecated` could be used.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 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/1447472

Title:
  versionutils.deprecated is used to mark callables as deprecated

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L420
  ~ #L423 intends to use versionutils.deprecated to deprecate the
  passing of `extras`, this is not the valid case
  versionutils.deprecated could be implied.

  see:
  
https://github.com/openstack/keystone/blob/master/keystone/openstack/common/versionutils.py#L165
  for where `versionutils.deprecated` could be used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1447472/+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 1443765] [NEW] Delete endpoint_group should remove project_endpoint_group at first

[Dave Chen]

Public bug reported:

Since the endpoint_group_id of table project_endpoint_group has a
foreign key reference with the id of endpoint_group, so if we want to
delete endpoint_group we need delete associated project_endpoint_group
at first, or else, it will hit follow exceptions:

{error: {message: An unexpected error prevented the server from
fulfilling your request: (IntegrityError) (1451, 'Cannot delete or
update a parent row: a foreign key constraint fails
(`keystone`.`project_endpoint_group`, CONSTRAINT
`project_endpoint_group_ibfk_1` FOREIGN KEY (`endpoint_group_id`)
REFERENCES `endpoint_group` (`id`))') 'DELETE FROM endpoint_group WHERE
endpoint_group.id = %s' ('d5c86622fea04c43b0c0e3b540417e1f',) (Disable
debug mode to suppress these details.), code: 500, title: Internal
Server Error}}

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  Delete endpoint_group should remove project_endpoint_group at first

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Since the endpoint_group_id of table project_endpoint_group has a
  foreign key reference with the id of endpoint_group, so if we want to
  delete endpoint_group we need delete associated project_endpoint_group
  at first, or else, it will hit follow exceptions:

  {error: {message: An unexpected error prevented the server from
  fulfilling your request: (IntegrityError) (1451, 'Cannot delete or
  update a parent row: a foreign key constraint fails
  (`keystone`.`project_endpoint_group`, CONSTRAINT
  `project_endpoint_group_ibfk_1` FOREIGN KEY (`endpoint_group_id`)
  REFERENCES `endpoint_group` (`id`))') 'DELETE FROM endpoint_group
  WHERE endpoint_group.id = %s' ('d5c86622fea04c43b0c0e3b540417e1f',)
  (Disable debug mode to suppress these details.), code: 500,
  title: Internal Server Error}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1443765/+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 1436704] [NEW] service is included in V3 catalog even with no endpoints

[Dave Chen]

Public bug reported:

This is actually the following up of the comment in this patch
(https://review.openstack.org/#/c/144860/19/keystone/catalog/backends/sql.py).

In current source, we just keep the service in the catalog with no
endpoints, we should skip the services as Henry's comments.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  service is included in V3 catalog even with no endpoints

Status in OpenStack Identity (Keystone):
  New

Bug description:
  This is actually the following up of the comment in this patch
  (https://review.openstack.org/#/c/144860/19/keystone/catalog/backends/sql.py).

  In current source, we just keep the service in the catalog with no
  endpoints, we should skip the services as Henry's comments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1436704/+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 1434599] [NEW] some issue with ec2 signature

[Dave Chen]

Public bug reported:

Beside the issue desribed in the bug#1289115, there are still other
issues found with that piece of code, part of these issue has been
confirmed with the original author.

something we need to fix:
- Check the colon from credentials['host'] instead of credentials['signature'].
- credentials['signature'] is not guaranteed to existed, so need to check it 
explicitly.
- Need reinitialize 'singer' to avoid contaminated status of signature.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 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/1434599

Title:
  some issue with ec2 signature

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Beside the issue desribed in the bug#1289115, there are still other
  issues found with that piece of code, part of these issue has been
  confirmed with the original author.

  something we need to fix:
  - Check the colon from credentials['host'] instead of 
credentials['signature'].
  - credentials['signature'] is not guaranteed to existed, so need to check it 
explicitly.
  - Need reinitialize 'singer' to avoid contaminated status of signature.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1434599/+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 1429723] [NEW] Column role_id of table assignment should be properly reference with table role

[Dave Chen]

Public bug reported:

'role_id' should be referenced with 'id' of 'role' table, but this is not 
specified in current code, see
https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L404

It seems the upgrade script is okay.
https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/038_add_assignment_table.py#L39

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Description changed:

- 'role_id' should be referenced with 'id' of 'role', but this is not specified 
in current code, see
+ 'role_id' should be referenced with 'id' of 'role' table, but this is not 
specified in current code, see
  
https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L404
- 
  
  It seems the upgrade script is okay.
  
https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/038_add_assignment_table.py#L39

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  Column role_id of table assignment should be properly reference with
  table role

Status in OpenStack Identity (Keystone):
  New

Bug description:
  'role_id' should be referenced with 'id' of 'role' table, but this is not 
specified in current code, see
  
https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L404

  It seems the upgrade script is okay.
  
https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/038_add_assignment_table.py#L39

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1429723/+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 1418398] [NEW] role not found and assignment not found mix up together

[Dave Chen]

Public bug reported:

Currently, basic role not found exception and role assignment with
specific role cannot be found are mixed up together, need add
RoleAssignment exception to differentiate from the basic role
exception will help reducing the confusion.

[1]
https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L172

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  role not found and assignment not found mix up together

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Currently, basic role not found exception and role assignment with
  specific role cannot be found are mixed up together, need add
  RoleAssignment exception to differentiate from the basic role
  exception will help reducing the confusion.

  [1]
  
https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L172

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1418398/+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 1416615] [NEW] add schema for some extension entities

[Dave Chen]

Public bug reported:

Entity like 'policy association' and 'project endpoint group' also need
validation on the parameters for creating and updating API.

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

Title:
  add schema for some extension entities

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Entity like 'policy association' and 'project endpoint group' also
  need validation on the parameters for creating and updating API.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1416615/+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 1399768] Re: migration ofr endpoint_filter failes due to foreign key constraint

[Dave Chen]

, in do_execute
31365 TRACE keystone cursor.execute(statement, parameters)
31365 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/MySQLdb/cursors.py, line 205, in 
execute
31365 TRACE keystone self.errorhandler(self, exc, value)
31365 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/MySQLdb/connections.py, line 36, in 
defaulterrorhandler
31365 TRACE keystone raise errorclass, errorvalue
31365 TRACE keystone OperationalError: (OperationalError) (1005, Can't create 
table 'keystone.project_endpoint_group' (errno: 150)) '\nCREATE TABLE 
project_endpoint_group (\n\tendpoint_group_id VARCHAR(64) NOT NULL, 
\n\tproject_id VARCHAR(64) NOT NULL, \n\tPRIMARY KEY (endpoint_group_id, 
project_id), \n\tFOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group 
(id)\n)\n\n' ()
31365 TRACE keystone


** Changed in: keystone
   Status: Invalid = New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  migration ofr endpoint_filter failes due to foreign key constraint

Status in OpenStack Identity (Keystone):
  New

Bug description:
   keystone-manage db_sync --extension endpoint_filter 2

  fails with

  
  2014-12-05 13:54:39.295 11241 TRACE keystone OperationalError: 
(OperationalError) (1005, Can't create table 'keystone.project_endpoint_group' 
(errno: 150)) '\nCREATE TABLE project_endpoint_group (\n\tendpoint_group_id 
VARCHAR(64) NOT NULL, \n\tproject_id VARCHAR(64) NOT NULL, \n\tPRIMARY KEY 
(endpoint_group_id, project_id), \n\tFOREIGN KEY(endpoint_group_id) REFERENCES 
endpoint_group (id)\n)\n\n' ()


  Migration 1 fails executing the below sql.

  
  CREATE TABLE project_endpoint_group (endpoint_group_id VARCHAR(64) NOT NULL, 
project_id VARCHAR(64) NOT NULL, PRIMARY KEY (endpoint_group_id, project_id), 
FOREIGN KEY(endpoint_group_id) REFERENCES endpoint_group (id));
  ERROR 1005 (HY000): Can't create table 'keystone.project_endpoint_group' 
(errno: 150)

  Removing the clause  FOREIGN KEY(endpoint_group_id) REFERENCES
  endpoint_group (id)) makes it work.

  THis is on Fedora 20 and I mariadb flavor of MySQL.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1399768/+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 1414627] [NEW] check whether V2 token is revoked has been performed twice

[Dave Chen]

Public bug reported:

Check whether V2 token is revoked or not has been performed twice,

First check is here, 
https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L247

Then in the func of _is_valid_token(token), the code check it again, 
https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L357

This is unnecessary and has been removed in the validate_v3_token(self,
token_id), need remove this code in validate_v2_token(...) as well.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  check whether V2 token is revoked has been performed twice

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Check whether V2 token is revoked or not has been performed twice,

  First check is here, 
  
https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L247

  Then in the func of _is_valid_token(token), the code check it again, 
  
https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L357

  This is unnecessary and has been removed in the
  validate_v3_token(self, token_id), need remove this code in
  validate_v2_token(...) as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1414627/+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 1405721] Re: test cases need cover new pattern of token provider configuration

[Dave Chen]

This perhaps is not a bug, the testcase is just trying to verify the
override case.

** Changed in: keystone
   Status: In Progress = 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/1405721

Title:
  test cases need cover new pattern of token provider configuration

Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  Check the testcase for the token provider from the source here.
  
https://github.com/openstack/keystone/blob/master/keystone/tests/test_token_provider.py#L776~L780
 for example, only old style of token provider configuaration is covered. 
  It's obvious  that there is something wrong with the testcase, besides, the 
function should also cover default token provider and 'PKIZ' as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1405721/+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 1405721] [NEW] test cases need cover new pattern of token provider configuration

[Dave Chen]

Public bug reported:

Check the testcase for the token provider from the source here.
https://github.com/openstack/keystone/blob/master/keystone/tests/test_token_provider.py#L776~L780
 for example, only old style of token provider configuaration is covered. 
It's obvious  that there is something wrong with the testcase, besides, the 
function should also cover default token provider and 'PKIZ' as well.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

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

Title:
  test cases need cover new pattern of token provider configuration

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Check the testcase for the token provider from the source here.
  
https://github.com/openstack/keystone/blob/master/keystone/tests/test_token_provider.py#L776~L780
 for example, only old style of token provider configuaration is covered. 
  It's obvious  that there is something wrong with the testcase, besides, the 
function should also cover default token provider and 'PKIZ' as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1405721/+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 1403408] [NEW] Redundant endpoints found in the table endpoint

[Dave Chen]

Public bug reported:

MariaDB [keystone] select * from endpoint where url = 
http://10.239.1.1:5010/v2.0; and interface = admin;
+--+--+---+--+-+---+-+---+
| id   | legacy_endpoint_id   | 
interface | service_id   | url | 
extra | enabled | region_id |
+--+--+---+--+-+---+-+---+
| 38a55638f08c4be1afdd3172f15c4144 | 2dcb5c14c4da4a22a060c78f073decac | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | RegionOne |
| a365f3fd58eb482fa44603fe83f8b2e0 | 26ef22b4dd8b487bb2f29f52cbbb2fec | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | regionOne |
| b0f41268a6b2438b92d977a464fd7f2d | 97b1ce4adc794b3598fb5a521e63276b | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | RegionOne |
| dd3c0c9880e74d55b4d7de71ac5207ac | 6d994b06ed8942cda56bd2c03cbc56c8 | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | regionOne |
+--+--+---+--+-+---+-+---+
4 rows in set (0.00 sec)

These entries has the same interface, same url etc. except id and
legacy_endpoint_id. User can create many redundant endpoints as long
as he/she wants to, just via the command like following:

keystone --debug endpoint-create --region RegionOne  --service
a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.239.1.1:5010/v2.0
--adminurl http://10.239.1.1:5010/v2.0 --internalurl
http://10.239.1.1:5010/v2.0

I'm not sure whether this is an intentional behavior, existed endpoints
check to avoid redundant entries seems is needed here.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

** Summary changed:

- Redundant endpoints found in table endpoint
+ Redundant endpoints found in the table endpoint

** Description changed:

  MariaDB [keystone] select * from endpoint where url = 
http://10.239.1.1:5010/v2.0; and interface = admin;
  
+--+--+---+--+-+---+-+---+
  | id   | legacy_endpoint_id   | 
interface | service_id   | url | 
extra | enabled | region_id |
  
+--+--+---+--+-+---+-+---+
  | 38a55638f08c4be1afdd3172f15c4144 | 2dcb5c14c4da4a22a060c78f073decac | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | RegionOne |
  | a365f3fd58eb482fa44603fe83f8b2e0 | 26ef22b4dd8b487bb2f29f52cbbb2fec | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | regionOne |
  | b0f41268a6b2438b92d977a464fd7f2d | 97b1ce4adc794b3598fb5a521e63276b | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | RegionOne |
  | dd3c0c9880e74d55b4d7de71ac5207ac | 6d994b06ed8942cda56bd2c03cbc56c8 | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | regionOne |
  
+--+--+---+--+-+---+-+---+
  4 rows in set (0.00 sec)
  
- 
  These entries has the same interface, same url etc. except id and
  legacy_endpoint_id. User can create many redundant endpoints as long
- as he/she wants, just via the command like following:
+ as he/she wants to, just via the command like following:
  
  keystone --debug endpoint-create --region RegionOne  --service
  a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.239.1.1:5010/v2.0
  --adminurl http://10.239.1.1:5010/v2.0 --internalurl
  http://10.239.1.1:5010/v2.0
  
- 
- I'm not sure whether this is an intentional behavior, existed endpoints check 
to avoid redundant entries seems is needed here.
+ I'm not sure whether this is an intentional behavior, existed endpoints
+ check to avoid redundant entries seems is needed here.

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

Title

[Yahoo-eng-team] [Bug 1402187] [NEW] Invalid token provider

[Dave Chen]

Public bug reported:

When specify token provoider as pkiz instead of full class path of
token provider as keystone.token.providers.[pkiz|pki|uuid].Provider in
keystone.conf I will get the following exception thrown in the log file.

2014-12-14 04:48:18.710721 Traceback (most recent call last):
2014-12-14 04:48:18.710732   File /var/www/keystone/main, line 53, in module
2014-12-14 04:48:18.710798 drivers = backends.load_backends()
2014-12-14 04:48:18.710817   File /opt/stack/keystone/keystone/backends.py, 
line 48, in load_backends
2014-12-14 04:48:18.710851 token_provider_api=token.provider.Manager())
2014-12-14 04:48:18.710867   File 
/opt/stack/keystone/keystone/common/dependency.py, line 200, in wrapper
2014-12-14 04:48:18.710944 self.__wrapped_init__(*args, **kwargs)
2014-12-14 04:48:18.710950   File 
/opt/stack/keystone/keystone/common/dependency.py, line 110, in 
__wrapped_init__
2014-12-14 04:48:18.710969 init(self, *args, **kwargs)
2014-12-14 04:48:18.710974   File 
/opt/stack/keystone/keystone/token/provider.py, line 152, in __init__
2014-12-14 04:48:18.711100 super(Manager, 
self).__init__(self.get_token_provider())
2014-12-14 04:48:18.711106   File 
/opt/stack/keystone/keystone/common/manager.py, line 70, in __init__
2014-12-14 04:48:18.711150 self.driver = 
importutils.import_object(driver_name)
2014-12-14 04:48:18.711165   File 
/usr/local/lib/python2.7/dist-packages/oslo/utils/importutils.py, line 38, in 
import_object
2014-12-14 04:48:18.711226 return import_class(import_str)(*args, **kwargs)
2014-12-14 04:48:18.711244   File 
/usr/local/lib/python2.7/dist-packages/oslo/utils/importutils.py, line 27, in 
import_class
2014-12-14 04:48:18.711252 __import__(mod_str)
2014-12-14 04:48:18.711264 ValueError: Empty module name

I understand the comment in keystone.conf has show us how to config
the provider but in my opinion, it should also support pkiz|pki|uuid
besides the full class path, or at least, there should be one dedicated
exception to show us what's wrong with the config. Seen from the code
there is no invalid provider checking, so invalid token provider
exception to show us what's wrong with the config is desired.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

** Description changed:

- When specify token provoider as pkiz instead of full class path of token 
provider as keystone.token.providers.[pkiz|pki|uuid].Provider in 
keystone.conf I will get the following exception thrown in the log file.
+ When specify token provoider as pkiz instead of full class path of
+ token provider as keystone.token.providers.[pkiz|pki|uuid].Provider in
+ keystone.conf I will get the following exception thrown in the log file.
+ 
  2014-12-14 04:48:18.710721 Traceback (most recent call last):
  2014-12-14 04:48:18.710732   File /var/www/keystone/main, line 53, in 
module
  2014-12-14 04:48:18.710798 drivers = backends.load_backends()
  2014-12-14 04:48:18.710817   File /opt/stack/keystone/keystone/backends.py, 
line 48, in load_backends
  2014-12-14 04:48:18.710851 token_provider_api=token.provider.Manager())
  2014-12-14 04:48:18.710867   File 
/opt/stack/keystone/keystone/common/dependency.py, line 200, in wrapper
  2014-12-14 04:48:18.710944 self.__wrapped_init__(*args, **kwargs)
  2014-12-14 04:48:18.710950   File 
/opt/stack/keystone/keystone/common/dependency.py, line 110, in 
__wrapped_init__
  2014-12-14 04:48:18.710969 init(self, *args, **kwargs)
  2014-12-14 04:48:18.710974   File 
/opt/stack/keystone/keystone/token/provider.py, line 152, in __init__
  2014-12-14 04:48:18.711100 super(Manager, 
self).__init__(self.get_token_provider())
  2014-12-14 04:48:18.711106   File 
/opt/stack/keystone/keystone/common/manager.py, line 70, in __init__
  2014-12-14 04:48:18.711150 self.driver = 
importutils.import_object(driver_name)
  2014-12-14 04:48:18.711165   File 
/usr/local/lib/python2.7/dist-packages/oslo/utils/importutils.py, line 38, in 
import_object
  2014-12-14 04:48:18.711226 return import_class(import_str)(*args, 
**kwargs)
  2014-12-14 04:48:18.711244   File 
/usr/local/lib/python2.7/dist-packages/oslo/utils/importutils.py, line 27, in 
import_class
  2014-12-14 04:48:18.711252 __import__(mod_str)
  2014-12-14 04:48:18.711264 ValueError: Empty module name
  
- I understand the comment in keystone.conf has show us how to config
- the provider but in my opinion, it should also support pkiz|pki|uuid
- besides the full class path, or at least, there should be one dedicated
- exception to show us what's wrong with the config. Seen from the code
- there is no invalid provider checking, so invalid token provider
- exception is preferred.
+ 
+ I understand the comment in keystone.conf has show us how to config the 
provider but in my opinion, it should also support pkiz|pki|uuid besides the 
full

[Yahoo-eng-team] [Bug 1400589] [NEW] default region name is inconsistent with the hint message

[Dave Chen]

Public bug reported:

It seems the name of the region is RegionOne with the initial character
R in upper case.

MariaDB [keystone] select * from region;
+---+-+--+---+--+
| id| description | parent_region_id | extra | url  |
+---+-+--+---+--+
| RegionOne | | NULL | {}| NULL |
| test  | | NULL | {}| NULL |
+---+-+--+---+--+

While I am try to create  one new endpoint with a new region which I hope would 
be regionOne, the command can be executed successfully,
$ keystone endpoint-create --region regionOne  --service 
a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.*.*.*:5010/v2.0 
--adminurl http://10.*.*.*:5010/v2.0 --internalurl http://10.*.*.*:5010/v2.0
+-+--+
|   Property  |  Value   |
+-+--+
|   adminurl  |  http://10.*.*.*:5010/v2.0  |
|  id | 8ffb333e32a54355bc924e7602362675 |
| internalurl |  http://10.*.*.*:5010/v2.0  |
|  publicurl  |  http://10.*.*.*:5010/v2.0  |
|region   |regionOne |
|  service_id | a1663c0dbba64425b5767688ac86fa10 |
+-+--+

But there is no new region named regionOne created in the database
other that the default one RegionOne, so I guess it treats both of
them the same.

But if I create the endpoint with RegionOne, the command can also success but 
the output message like this,
$ keystone endpoint-create --region RegionOne  --service 
a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.*.*.*:5010/v2.0 
--adminurl http://10.*.*.*:5010/v2.0 --internalurl http://10.*.*.*:5010/v2.0
+-+--+
|   Property  |  Value   |
+-+--+
|   adminurl  |  http://10.*.*.*:5010/v2.0  |
|  id | 075b237859c149128c3bbf8c3556922d |
| internalurl |  http://10.*.*.*:5010/v2.0  |
|  publicurl  |  http://10.*.*.*:5010/v2.0  |
|region   |RegionOne |
|  service_id | a1663c0dbba64425b5767688ac86fa10 |
+-+--+

It make me confusion about what's behind about the region, so file this
bug to track this.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

** Description changed:

  It seems the name of the region is RegionOne with the initial character
  R in upper case.
  
  MariaDB [keystone] select * from region;
  +---+-+--+---+--+
  | id| description | parent_region_id | extra | url  |
  +---+-+--+---+--+
  | RegionOne | | NULL | {}| NULL |
  | test  | | NULL | {}| NULL |
  +---+-+--+---+--+
  
- 
- While I am try to create  one new endpoint with a new region which i hope 
would regionOne, the command can executed successfully, 
+ While I am try to create  one new endpoint with a new region which I hope 
would be regionOne, the command can be executed successfully,
  $ keystone endpoint-create --region regionOne  --service 
a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.*.*.*:5010/v2.0 
--adminurl http://10.*.*.*:5010/v2.0 --internalurl http://10.*.*.*:5010/v2.0
  +-+--+
  |   Property  |  Value   |
  +-+--+
  |   adminurl  |  http://10.*.*.*:5010/v2.0  |
  |  id | 8ffb333e32a54355bc924e7602362675 |
  | internalurl |  http://10.*.*.*:5010/v2.0  |
  |  publicurl  |  http://10.*.*.*:5010/v2.0  |
  |region   |regionOne |
  |  service_id | a1663c0dbba64425b5767688ac86fa10 |
  +-+--+
  
  But there is no new region named regionOne created in the database
  other that the default one RegionOne, so I guess it treats both of
  them the same.
  
- 
  But if I create the endpoint with RegionOne, the command can also success 
but the output message like this,
  $ keystone endpoint-create --region RegionOne  --service 
a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.*.*.*:5010/v2.0 
--adminurl http://10.*.*.*:5010/v2.0 --internalurl http://10.*.*.*:5010/v2.0
  +-+--+
  |   Property  |  Value   |
  +-+--+
  |   adminurl  |  http://10.*.*.*:5010/v2.0  |
  |  id | 075b237859c149128c3bbf8c3556922d |
  | internalurl |  http://10.*.*.*:5010/v2.0  |
  |  publicurl  |  http://10.*.*.*:5010/v2.0

[Yahoo-eng-team] [Bug 1369388] [NEW] local configuration is not allowed in keystone-paste.ini

[Dave Chen]

/paste/deploy/loadwsgi.py, line 350, in 
get_app
[Sun Sep 14 22:40:37.317100 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] name=name, global_conf=global_conf).create()
[Sun Sep 14 22:40:37.317104 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590]   File 
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create
[Sun Sep 14 22:40:37.317121 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] return self.object_type.invoke(self)
[Sun Sep 14 22:40:37.317125 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590]   File 
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 207, in invoke
[Sun Sep 14 22:40:37.317132 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] app = filter(app)
[Sun Sep 14 22:40:37.317136 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590]   File 
/opt/stack/keystone/keystone/common/wsgi.py, line 406, in _factory
[Sun Sep 14 22:40:37.317278 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] return cls(app, **local_config)
[Sun Sep 14 22:40:37.317301 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] TypeError: __init__() got an unexpected keyword 
argument 'redis_host'.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Changed in: openstack-manuals
 Assignee: (unassigned) = Dave Chen (wei-d-chen)

** Project changed: openstack-manuals = keystone

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

Title:
  local configuration is not allowed in keystone-paste.ini

Status in OpenStack Identity (Keystone):
  New

Bug description:
  According to funcation docs in keystone/common/wsgi.py, local configuration 
is allowed in the paste.deploy config files, such as redis_host.
  380 @classmethod
  381 def factory(cls, global_config, **local_config):
  382 Used for paste app factories in paste.deploy config files.
  383
  384 Any local configuration (that is, values under the 
[filter:APPNAME]
  385 section of the paste config) will be passed into the `__init__` 
method
  386 as kwargs.
  387
  388 A hypothetical configuration would look like:
  389
  390 [filter:analytics]
  391 redis_host = 127.0.0.1
  392 paste.filter_factory = keystone.analytics:Analytics.factory
  393
  394 which would result in a call to the `Analytics` class as
  395
  396 import keystone.analytics
  397 keystone.analytics.Analytics(app, redis_host='127.0.0.1')
  398
  399 You could of course re-implement the `factory` method in 
subclasses,
  400 but using the kwarg passing it shouldn't be necessary.
  401
  402 

  And in the following implemenation, local configuration is indeed readed from 
paste.deploy config files.
  406 return cls(app, **local_config)

  But, the local_config is not allowed in the constructor where only app is 
passed into the constructor.
  409 def __init__(self, application):
  410 super(Middleware, self).__init__()
  411 self.application = application

  So, if we configure paste.deploy config files like what the method docs says, 
it will always fails as:
  [Sun Sep 14 22:40:37.316517 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] mod_wsgi (pid=22196): Exception occurred processing 
WSGI script '/var/www/keystone/admin'.
  [Sun Sep 14 22:40:37.316554 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] Traceback (most recent call last):
  [Sun Sep 14 22:40:37.316564 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590]   File /var/www/keystone/admin, line 59, in 
module
  [Sun Sep 14 22:40:37.316626 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] name=name)
  [Sun Sep 14 22:40:37.316644 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590]   File 
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in 
loadapp
  [Sun Sep 14 22:40:37.316795 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] return loadobj(APP, uri, name=name, **kw)
  [Sun Sep 14 22:40:37.316803 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590]   File 
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in 
loadobj
  [Sun Sep 14 22:40:37.316822 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590] return context.create()
  [Sun Sep 14 22:40:37.316827 2014] [:error] [pid 22196:tid 139709922383616] 
[remote 10.239.4.160:27590]   File 
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create