[Yahoo-eng-team] [Bug 1373232] Re: The ldap driver needs to bubble up some ldap exceptions
LDAP is now read-only so this specific issue no longer applies. Please
re-open if you still have problems that are unrelated to writing.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1373232
Title:
The ldap driver needs to bubble up some ldap exceptions
Status in OpenStack Identity (keystone):
Won't Fix
Bug description:
LDAP driver can bubble up some exceptions as 400 errors.
Example ldap.CONSTRAINT_VIOLATION and ldap.UNWILLING
def update_user(self, user_id, user):
self.user.check_allow_update()
if 'id' in user and user['id'] != user_id:
raise exception.ValidationError(_('Cannot change user ID'))
old_obj = self.user.get(user_id)
#Defect 118381, user name update in ldap should be allowed.
#if 'name' in user and old_obj.get('name') != user['name']:
# raise exception.Conflict(_('Cannot change user name'))
#user = utils.hash_ldap_user_password(user)
if self.user.enabled_mask:
self.user.mask_enabled_attribute(user)
try:
self.user.update(user_id, user, old_obj)
except ldap.CONSTRAINT_VIOLATION as e:
if 'info' in e[0]:
raise exception.ValidationError(e[0]['info'])
else:
raise AssertionError(_('Error updating user'))
return self.user.get_filtered(user_id)
https://github.com/openstack/keystone/blob/1af24284bdc093dae4f027ade2ddb29656b676f0/keystone/identity/backends/ldap.py#L95-L111
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1373232/+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 1674676] Re: The URL listed against the details of identity resources returns 404 Not Found error
Feel free to reoen if this is actually causing issues in a deployment. ** Changed in: keystone Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1674676 Title: The URL listed against the details of identity resources returns 404 Not Found error Status in OpenStack Identity (keystone): Invalid Bug description: Many of the details referencing the relationship between the operation and the resource return 404 Not Found when you try and follow the link. For example, the details of the endpoint given against the following URL: https://developer.openstack.org/api- ref/identity/v3/index.html?expanded=create-endpoint-detail#create- endpoint Points to: https://docs.openstack.org/api/openstack-identity/3/rel/endpoints To describe the relationship but results in a 404 Not Found error. This issue it consistent across many of the relationship links. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1674676/+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 1662453] Re: Mitika domain name defaults to Keystone Architecture Document Inconsistent description
I'm going to close this because I don't think it's a bug. I'm not sure how it got set to Default, but the important thing is that its ID is the ID specified in the config as [identity]default_domain_id. Feel free to open this back up if it causes you problems in your installation. ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1662453 Title: Mitika domain name defaults to Keystone Architecture Document Inconsistent description Status in OpenStack Identity (keystone): Invalid Bug description: I have a openstack production environment.I don't know if it's a problem. In kilo, domain name is Default.but in mitika ,domain name is default. however,In Keystone Architecture Document.The default value for the domain name presentation is Default, Mitika environment installed according to installation documentation,I check the database project table domain name is default. when kilo upgrade to mitika ，domain name is Default. Lead me to use domain name to get token can not determine the value of name. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1662453/+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 1661601] Re: keystone.middleware.auth logs an opaque debug message
(Note: keystone doesn't do XML anymore so that request wouldn't work anymore) The error message in question 'There is either no auth token in the request...' is a debug message that is meant to help us while developing. It really is there to let us know that no token, cert, etc. was included in the request. In the case if getting a token that's always going to be logged since you don't yet have a token. So you have 1 successful REST request using the API and another successful requestion using the openstack client. I originally thought that specifying the domain name was broken. It worked fine for me so I took a closer look at your request and found that there we lots of JSON errors. 1. Use 'Default' and not 'default' when specifying the name. 2. There are a few places that don't open or close double quotes properly 3. There is a period instead of a comma in between the identity and scope sections 4. There is a ) instead of a } to end the domain section ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1661601 Title: keystone.middleware.auth logs an opaque debug message Status in OpenStack Identity (keystone): Invalid Bug description: Whether using curl or xml with correct credentials continue to get the following message in the logs: http://cdn.pasteraw.com/oolimjgy2xxrxpd9u98xmzl8mgs7xk Here is one set of xml code: (both xml and curl script below result in above error) curl -i -X POST -H "X-Autplication/xml" http://haproxy2-st:35357/v3/auth/tokens -d 'password' Here is another set of xml code: http://haproxy2-st:35357/v3"/> Here is curl script: http://cdn.pasteraw.com/r9ssqhtfk60rcaoju4extlee30x5a6p Contents of admin.sh that works: http://cdn.pasteraw.com/c2jwo3s5ib6ru4yhdfaz1afesrbsidt The following is debug output of the `openstack token issue` command: http://cdn.pasteraw.com/d0el13vpr87k6xj3cbc4qztnd2aeaim To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1661601/+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 1672425] Re: No 'options' attribute in user_ref when using LDAP identity backend
*** This bug is a duplicate of bug 1662762 *** https://bugs.launchpad.net/bugs/1662762 The fix for this was merged to master and was backported to ocata. ** This bug has been marked a duplicate of bug 1662762 Authentication for LDAP user fails at MFA rule check -- 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/1672425 Title: No 'options' attribute in user_ref when using LDAP identity backend Status in OpenStack Identity (keystone): In Progress Bug description: While testing the ocata codebase, it seems that the addition of the multifactor auth in core, breaks our LDAP identity backend. We are getting an exception while loading the user to check if it has MFA enabled or not. The LDAP identity driver does not provide a options attribute for the user and then it throws an exception in this specific line (https://github.com/openstack/keystone/blob/8ff15d3e0fc2cf1bdfb202c54a6816a9676119fe/keystone/auth/core.py#L377) For giving some context, these are the 2 lines concerned (keystone/auth/core.py) 376:user_ref = self.identity_api.get_user(user_id) 377:mfa_rules = user_ref['options'].get(ro.MFA_RULES_OPT.option_name, []) The first one loads the user from the identity driver and the 2nd one uses an attribute that does not exist in LDAP implementation, so it throws an exception To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1672425/+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 1672988] Re: Getting random string instead of lower case name as domin id
This isn't a bug, it's just describing the implementation details. A better forum for this would be the IRC channel. I don't think names have to be URL safe, so that makes using it harder. Projects and domains are in the same table so it would be a very strange design to have some IDs be UUID and others be a transformation of the name. This is just a design choice. We could do something else, but there would have to be a strong usecase for it. ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1672988 Title: Getting random string instead of lower case name as domin id Status in OpenStack Identity (keystone): Invalid Bug description: The 'Default' domain was created with 'default' id, but for all other domain I got some random string as an id. The domain names are unique, and compared in a case intensive way, therefore lowercase names can be ids. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1672988/+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 1667872] Re: Install keystone error
"error in setup command: Error parsing /home/smartcity/Desktop/idm
/keystone-keyrock-5.4.0/setup.cfg: Exception: Versioning for this
project requires either an sdist tarball, or access to an upstream git
repository. Are you sure that git is installed?"
This doesn't look like a keystone bug to me. Feel free to reopen if I am
incorrect.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1667872
Title:
Install keystone error
Status in OpenStack Identity (keystone):
Invalid
Bug description:
Error install afer run sudo command :
$ python tools/install_venv.py
Info:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
attrs = util.cfg_to_args(path)
File "/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 243, in
cfg_to_args
pbr.hooks.setup_hook(config)
File "/usr/local/lib/python2.7/dist-packages/pbr/hooks/__init__.py", line
25, in setup_hook
metadata_config.run()
File "/usr/local/lib/python2.7/dist-packages/pbr/hooks/base.py", line 27,
in run
self.hook()
File "/usr/local/lib/python2.7/dist-packages/pbr/hooks/metadata.py", line
26, in hook
self.config['name'], self.config.get('version', None))
File "/usr/local/lib/python2.7/dist-packages/pbr/packaging.py", line 654,
in get_version
raise Exception("Versioning for this project requires either an sdist"
Exception: Versioning for this project requires either an sdist tarball, or
access to an upstream git repository. Are you sure that git is installed?
error in setup command: Error parsing
/home/smartcity/Desktop/idm/keystone-keyrock-5.4.0/setup.cfg: Exception:
Versioning for this project requires either an sdist tarball, or access to an
upstream git repository. Are you sure that git is installed?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1667872/+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 1641026] Re: Keystone ldap tree_dn does not support Chinese
** Also affects: oslo.config 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/1641026 Title: Keystone ldap tree_dn does not support Chinese Status in OpenStack Identity (keystone): Incomplete Status in oslo.config: New Bug description: Keystone ldap tree_dn does not support Chinese My keystone.conf: url = ldap://10.153.195.125 user = CN=Administrator,CN=Users,DC=h3c,DC=com password = h3C123456 suffix = DC=h3c,DC=com query_scope = sub user_tree_dn = OU=华三,DC=h3c,DC=com ... ... My tree_dn config ou is Chinese,I try login openstack dashboard It throw:UnicodeDecodeError:'ascii' codes can't decode bytes 0xe5 in position 3:ordinal not in range(128) I think tree_dn need unicode. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1641026/+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 1592713] Re: wrong url for list role identity v2 API
This was fixed in https://review.openstack.org/#/c/343130/ ** Changed in: keystone Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1592713 Title: wrong url for list role identity v2 API Status in OpenStack Identity (keystone): Fix Released Bug description: Keystone has list roles API but its url is wrong here- http://developer.openstack.org/api-ref-identity-v2-ext.html#listRoles It should be '/v2.0/OS-KSADM/roles' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1592713/+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 1602714] [NEW] [api-ref] OS-ENDPOINT-POLICY docs need work
Public bug reported: The API calls are not in a logical order. Some of the calls are incorrect and missing info. ** Affects: keystone Importance: Low Assignee: David Stanek (dstanek) Status: Confirmed -- 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/1602714 Title: [api-ref] OS-ENDPOINT-POLICY docs need work Status in OpenStack Identity (keystone): Confirmed Bug description: The API calls are not in a logical order. Some of the calls are incorrect and missing info. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1602714/+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 1600109] Re: Unit tests should not perform logging, but some tests still use
Marking as WONTFIX for now because I don't think this is a keystone issue at all. If you find a place in keystone where there is a problem feel free to reopen. ** Changed in: keystone Status: Incomplete => Won't Fix ** Changed in: python-keystoneclient Status: Incomplete => Won't Fix -- 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/1600109 Title: Unit tests should not perform logging,but some tests still use Status in Ceilometer: Incomplete Status in Cinder: Incomplete Status in Glance: Incomplete Status in glance_store: Incomplete Status in OpenStack Identity (keystone): Won't Fix Status in Magnum: Incomplete Status in neutron: Incomplete Status in OpenStack Compute (nova): Incomplete Status in os-brick: Incomplete Status in python-cinderclient: Incomplete Status in python-glanceclient: Incomplete Status in python-heatclient: Incomplete Status in python-keystoneclient: Won't Fix Status in python-neutronclient: Incomplete Status in python-novaclient: Incomplete Status in python-rackclient: Incomplete Status in python-swiftclient: Incomplete Status in rack: Incomplete Status in Rally: Incomplete Status in OpenStack Object Storage (swift): Incomplete Status in tempest: Incomplete Status in OpenStack DBaaS (Trove): Incomplete Bug description: We shuld remove the logging To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1600109/+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 1592646] Re: Need to write "update user's password" on identity v2 API
I don't know that anyone will want to put in the effort to do this since we really don't want anyone to use v2. ** 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/1592646 Title: Need to write "update user's password" on identity v2 API Status in OpenStack Identity (keystone): Opinion Bug description: Bug https://bugs.launchpad.net/openstack-api-site/+bug/1524147 is not fixed yet. I did not find update password API doc http://developer.openstack.org /api-ref-identity-admin-v2.html or http://developer.openstack.org /api-ref-identity-v2-ext.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1592646/+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 1600268] [NEW] Upgrading from Liberty to Mitaka erased passwords from SQL backend
Public bug reported: This bug was reported in IRC on July 7, 2016 by jmlowe. Creating this for tracking purposes. IRC log: http://eavesdrop.openstack.org/irclogs/%23openstack-keystone /%23openstack-keystone.2016-07-07.log.html Environment: - 3 total controllers (2 RDO and 2 Ubuntu) - all installed from vendor packages - 3 node Galera cluster - installed Liberty circa-December 2015 - upgraded to recent Mitaka version jmlowe found that after the migration LDAP users could login fine, but SQL users could not. Upon further investigation the password hashes were no longer in the database (the new `password` table was empty). The lack of password records in the Passwords table and the fact that the password column was removed from the User table leads me to believe that migration 091 is to blame. So far I have not been able to reproduce the issue. ** Affects: keystone Importance: Undecided Status: Incomplete ** Tags: upgrade ** Changed in: keystone Status: New => Incomplete -- 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/1600268 Title: Upgrading from Liberty to Mitaka erased passwords from SQL backend Status in OpenStack Identity (keystone): Incomplete Bug description: This bug was reported in IRC on July 7, 2016 by jmlowe. Creating this for tracking purposes. IRC log: http://eavesdrop.openstack.org/irclogs/%23openstack-keystone /%23openstack-keystone.2016-07-07.log.html Environment: - 3 total controllers (2 RDO and 2 Ubuntu) - all installed from vendor packages - 3 node Galera cluster - installed Liberty circa-December 2015 - upgraded to recent Mitaka version jmlowe found that after the migration LDAP users could login fine, but SQL users could not. Upon further investigation the password hashes were no longer in the database (the new `password` table was empty). The lack of password records in the Passwords table and the fact that the password column was removed from the User table leads me to believe that migration 091 is to blame. So far I have not been able to reproduce the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1600268/+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 1593542] Re: Keystone-manage bootstrap can't bootstrap domains other than default
I think this should be marked as WONTFIX. This feature is currently designed to be used when first installing keystone and not for creating new domains. ** 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/1593542 Title: Keystone-manage bootstrap can't bootstrap domains other than default Status in OpenStack Identity (keystone): Opinion Bug description: When using keystone-manage bootstrap, you can't define the domain that you want to bootstrap. It will always work with default. The problem is this doesn't help with a multi-domain environment. An admin user defined in the default domain doesn't have any permissions in other domains. Once a new domain is created a different admin user specific to that domain would need to be created in order to be able to act within it. If the keystone-manage bootstrap utility could allow bootstrapping of non-default domains then it could facilitate the administration of larger, multi-domain cloud environments without the security concern that arises from the older admin_token method. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1593542/+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 1591916] Re: Named arguments should be used for assertValidUserResponse() in unittest case
I'm marking this as opinion because I think it's better the way that it currently is, but I'd be open to changing my mind with a good argument. To me there is minimal benefit to making a change like this and it's definitely not a bug. ** Changed in: keystone Status: In Progress => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1591916 Title: Named arguments should be used for assertValidUserResponse() in unittest case Status in OpenStack Identity (keystone): Opinion Bug description: In the keystone unittest of test_v3_identity.py, there are two functions used in the IdentityTestCase, one is assertValidUserListResponse() and another is assertValidUserResponse(). These two functions eventually used this RestfulTestCase.assertValidUser(), and for the above two functions are call in different style. self.assertValidUserListResponse(r, ref=self.user, resource_url=resource_url) self.assertValidUserResponse(r, user) the assertValidUserListResponse() is called with named argument "ref=self.user", but the assertValidUserResponse() is not. Although, this won't cause any problem, but it would be better to unify the function call. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1591916/+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 1572202] [NEW] testresources needs to be explicitly required for tests
Public bug reported:
I get the following traceback when trying to run tests from master:
Failed to import test module: keystone.tests.unit.test_sql_upgrade
Traceback (most recent call last):
File
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
line 456, in _find_test_path
module = self._get_module_from_name(name)
File
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
line 395, in _get_module_from_name
__import__(name)
File "keystone/tests/unit/test_sql_upgrade.py", line 42, in
from oslo_db.sqlalchemy import test_base
File
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/test_base.py",
line 17, in
import testresources
ImportError: No module named testresources
The test run didn't actually run any tests
Explicitly requiring testresources for tests fixes the issue.
** Affects: keystone
Importance: Undecided
Assignee: David Stanek (dstanek)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1572202
Title:
testresources needs to be explicitly required for tests
Status in OpenStack Identity (keystone):
In Progress
Bug description:
I get the following traceback when trying to run tests from master:
Failed to import test module: keystone.tests.unit.test_sql_upgrade
Traceback (most recent call last):
File
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
line 456, in _find_test_path
module = self._get_module_from_name(name)
File
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
line 395, in _get_module_from_name
__import__(name)
File "keystone/tests/unit/test_sql_upgrade.py", line 42, in
from oslo_db.sqlalchemy import test_base
File
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/test_base.py",
line 17, in
import testresources
ImportError: No module named testresources
The test run didn't actually run any tests
Explicitly requiring testresources for tests fixes the issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1572202/+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 1280084] Re: get trust missing @controller.protected
Marking as WONTFIX because we can't really add the decorator at this point. ** Changed in: keystone Status: Confirmed => 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/1280084 Title: get trust missing @controller.protected Status in OpenStack Identity (keystone): Won't Fix Bug description: Currently, there is no @controller.protected decorator surrounding the get_trust function at the trust controller level. Since there is an entry for it in our sample policy.json files, it probably should be protected. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1280084/+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 1454531] Re: list_user_projects() can't get filtered by 'domain_id'.
** Changed in: keystone
Status: Fix Released => In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1454531
Title:
list_user_projects() can't get filtered by 'domain_id'.
Status in OpenStack Identity (keystone):
In Progress
Bug description:
Here is our use case, we want our tenant domain admin(e.g., Bob) to
have this capability: Bob(domain-scoped) can list the projects that
one user has roles on, and the projects Bob get should only belong to
Bob's scoping domain.
When we read the rule in policy.v3cloudsample.json for
"identity:list_user_projects", we are happy it's the same as what we want:
{...
"admin_and_matching_domain_id": "rule:admin_required and
domain_id:%(domain_id)s",
"identity:list_user_projects": "rule:owner or
rule:admin_and_matching_domain_id",
...}
I thought we could use this API with query string 'domain_id', thus
Bob can and only can query projects in his scoping domain, but it
doesn't work, since the @controller.filterprotected('enabled',
'name') for list_user_projects() exclude the possibility of taking
'domain_id' as a query string even it's useful to us and recorded in
the policy file.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1454531/+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 1519449] Re: Remove Python 2.6 Support
We removed 2.6 support from the server in Kilo. ** 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 OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1519449 Title: Remove Python 2.6 Support Status in OpenStack Identity (keystone): Invalid Status in keystoneauth: In Progress Status in keystonemiddleware: In Progress Status in pycadf: Invalid Status in python-keystoneclient: In Progress Status in python-keystoneclient-kerberos: In Progress Bug description: Remove the support for python 2.6 Tasks: Remove Gate Job Remove Tox.ini cruft Remove python 2.6 specific code. Remove the trove classifiers. This is a tracking bug so that anyone can tag work towards this on to a known point for the Mitaka release. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1519449/+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 1519449] Re: Remove Python 2.6 Support
Looks like pycadf is already 2.6 free. ** Changed in: pycadf Status: In Progress => Invalid ** Changed in: keystonemiddleware Assignee: Keystone Drivers (keystone-drivers) => David Stanek (dstanek) -- 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/1519449 Title: Remove Python 2.6 Support Status in OpenStack Identity (keystone): In Progress Status in keystoneauth: In Progress Status in keystonemiddleware: In Progress Status in pycadf: Invalid Status in python-keystoneclient: In Progress Status in python-keystoneclient-kerberos: New Bug description: Remove the support for python 2.6 Tasks: Remove Gate Job Remove Tox.ini cruft Remove python 2.6 specific code. This is a tracking bug so that anyone can tag work towards this on to a known point for the Mitaka release. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1519449/+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 1490497] Re: pep8-incompliant filenames missing in gate console logs
Marking as invalid because there isn't anything that can be fixed in Python. Maybe this is a flake8 issue? ** 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/1490497 Title: pep8-incompliant filenames missing in gate console logs Status in hacking: Incomplete Status in Keystone: Invalid Bug description: Jenkins reported gate-keystone-pep8 failure on patch set 12 @ https://review.openstack.org/#/c/209524/ . But the console logs didn't contain the filenames that are incompliant with pep8. http://logs.openstack.org/24/209524/12/check/gate-keystone-pep8/b2b7500/console.html ... 2015-08-30 22:34:11.101 | pep8 runtests: PYTHONHASHSEED='3894393079' 2015-08-30 22:34:11.102 | pep8 runtests: commands[0] | flake8 2015-08-30 22:34:11.102 | /home/jenkins/workspace/gate-keystone-pep8$ /home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8 2015-08-30 22:34:16.619 | ERROR: InvocationError: '/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8' 2015-08-30 22:34:16.620 | ___ summary 2015-08-30 22:34:16.620 | ERROR: pep8: commands failed ... Typically, it contains the filenames as well. Eg. Console logs pf patchset 1 contains the filenames. http://logs.openstack.org/24/209524/1/check/gate-keystone-pep8/19f2885/console.html ... 2015-08-05 14:45:15.247 | pep8 runtests: PYTHONHASHSEED='1879982710' 2015-08-05 14:45:15.247 | pep8 runtests: commands[0] | flake8 2015-08-05 14:45:15.247 | /home/jenkins/workspace/gate-keystone-pep8$ /home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8 2015-08-05 14:45:20.518 | ./keystone/assignment/backends/ldap.py:37:5: E301 expected 1 blank line, found 0 2015-08-05 14:45:20.518 | @versionutils.deprecated( 2015-08-05 14:45:20.518 | ^ ... 2015-08-05 14:45:20.872 | ERROR: InvocationError: '/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8' 2015-08-05 14:45:20.872 | ___ summary 2015-08-05 14:45:20.873 | ERROR: pep8: commands failed ... To manage notifications about this bug go to: https://bugs.launchpad.net/hacking/+bug/1490497/+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 1473489] Re: Identity API v3 does not accept more than one query parameter
Since this can't be reproduced and we haven't heard back from the reporter I'm marking this as Won't Fix. If you feel this is incorrect please reopen with an explanation. ** Changed in: keystone Status: Incomplete => Won't Fix ** Changed in: keystone Status: Won't Fix => 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/1473489 Title: Identity API v3 does not accept more than one query parameter Status in Keystone: Invalid Bug description: When GET /v3/users?name="blah"="true" is called the API would only take the "name" query and omits the "enabled" query. This is also reproduced across many different queries, including /v3/credentials. This looks like a repeat of https://bugs.launchpad.net/keystone/+bug/1424745 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1473489/+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 1489260] Re: trust details unavailable for admin token
Closing based on Steve's comments. Please reopen if you don't think this is reasonable. ** Changed in: keystone Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1489260 Title: trust details unavailable for admin token Status in Keystone: Won't Fix Bug description: When authenticated via admin token, trusts details are not available. Trusts can be listed: --- # openstack trust list -f csv "ID","Expires At","Impersonation","Project ID","Trustee User ID","Trustor User ID" "259d57b4998c484892ae3bdd7a84f147","2101-01-01T01:01:01.00Z",False,"a41030cd0872497893c0f00a29996961","64eea97a9ea54981a41cc7e40944a181","6bb8aef337134b948dcbc0bd6ac34633" --- But details cannot be shown: --- # openstack trust show 259d57b4998c484892ae3bdd7a84f147 ERROR: openstack No trust with a name or ID of '259d57b4998c484892ae3bdd7a84f147' exists. --- From the debug mode we can see the rejected authorization to perform the requested action: http://paste.openstack.org/raw/427927/ I discussed the issue with jamielennox who confirmed that the trust details are visible only by the trustor/trustee: https://github.com/openstack/keystone/blob/master/keystone/trust/controllers.py#L75 But I believe (and jamielennox) that the admin token should have access to it too. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1489260/+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 1490764] Re: Wrong handling of domain_id passed as None
@Lei, I think the key can be None from the V2 API. I think most cases in V3 make it a string or it can't be provided at all. @Henrique, How is the handing wrong? ** Changed in: keystone Status: Invalid => New ** Changed in: keystone Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1490764 Title: Wrong handling of domain_id passed as None Status in Keystone: Incomplete Bug description: Keystone does not handle the domain_id passed as none in controller layer, as in: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L743 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1490764/+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 1123462] Re: run_tests.sh does not work if keystone is not installed
run_tests.sh was deleted in https://review.openstack.org/#/c/199343/ ** Changed in: keystone Status: Confirmed => 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/1123462 Title: run_tests.sh does not work if keystone is not installed Status in Keystone: Won't Fix Bug description: Attempting to run unit tests from a checked out tree with run_tests.sh fails with 38 errors similar to this: == ERROR: Failure: ImportError (No module named keystone.common) -- Traceback (most recent call last): File "/home/johannes/virtualenvs/keystone/lib/python2.6/site-packages/nose/loader.py", line 390, in loadTestsFromName addr.filename, addr.module) File "/home/johannes/virtualenvs/keystone/lib/python2.6/site-packages/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/home/johannes/virtualenvs/keystone/lib/python2.6/site-packages/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/home/johannes/openstack/keystone/trunk/tests/test_wsgi.py", line 19, in from keystone.common import wsgi ImportError: No module named keystone.common It appears that the python path is not setup correctly when using run_tests.sh. This same workflow works in nova, glance and quantum. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1123462/+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 1461183] Re: keystone/tests/unit/test_v3.py:RestfulTestCase.load_sample_data still uses the assignment_api
The assignment's add_role_to_user_and_project is not deprecated and can be used by the tests. Once some of the assignment_api was deprecated when the resource_api was created, not all of it. ** Changed in: keystone Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1461183 Title: keystone/tests/unit/test_v3.py:RestfulTestCase.load_sample_data still uses the assignment_api Status in Keystone: Won't Fix Bug description: All test classes that inherit keystone/tests/unit/test_v3.py:RestfulTestCase run a load_sample_data method [0]. This method creates some sample data to test with and it still uses the assignment API, which has been deprecated. This method should be refactored to use the resource API instead. [0] https://github.com/openstack/keystone/blob/f6c01dd1673b290578e9fff063e27104412ffeda/keystone/tests/unit/test_v3.py#L235-L240 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1461183/+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 1461822] Re: Lack of password complexity verification in Keystone
Marking as WONTFIX because we are actively trying not to build a full IdP solution into Keystone. ** Changed in: keystone Status: Triaged = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1461822 Title: Lack of password complexity verification in Keystone Status in Keystone: Won't Fix Bug description: Currently, we can specified an arbitrary string as password when creating a user (or updating user's password) by keystone. In normally use cases, the user's password shouldn't be weak, because it may cause potential security issues. Keystone should add a mechanism to perform password complexity verification, and to fit different scenarios, this mechanism can be enabled or disabled by config option. The checking rules should follow the industry general standard. There is a similar situation about instance's password in Nova, see bug[1] and mail thread[2]. [1] https://bugs.launchpad.net/nova/+bug/1461431 [2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/065600.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1461822/+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 1462152] Re: python-memcache (and therefore) token memcache persistence driver does not support ipv6
Marking as WONTFIX since there isn't any work to be done on Keystone. ** Changed in: keystone Status: Triaged = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1462152 Title: python-memcache (and therefore) token memcache persistence driver does not support ipv6 Status in Keystone: Won't Fix Status in openstack-manuals: Confirmed Bug description: (morganfainberg): OpenStack Manuals (for both Master and Kilo) need to be updated to eliminate the recommendation to use the memcache token persistence backend. The memcache token persistence backend is a poor choice due to performance concerns of the code itself, the fact that it is assumed that the token backend is stable storage (memcached is not) and can expose security concerns if restarted in some scenarios (PKI tokens and revoked tokens becoming valid again), and finally that the python-memcache library is all around poor (it will not work with IPv6 and is not Python3 compatible, among other poor design choices). The memcache backend driver that utilizes python-memcache does not support IPv6. I have included three scenarios (A, B and C) that will reproduce the bug and a control test that succeeds with same configuration using IPv4-resolving hostname. To reproduce scenario A: Bare IPv6 address in config 1) Configure keystone according to http://docs.openstack.org/kilo/install-guide/install/apt/content/keystone-install.html 2) In section [memcache] in /etc/keystone/keystone.conf change servers = line: servers = 2001:db8:1000:1:f816:3eff:fe2a:f9c7:11211,2001:db8:1000:1:f816:3eff:fee9:9ce3:11211,2001:db8:1000:1:f816:3eff:fead:8f7f:11211 3) Restart keystone/apache 4) Attempt to issue token: openstack --os-auth-url http://192.168.0.15:35357 --os-project-name admin --os-username admin --os-auth-type password token issue ERROR: openstack An unexpected error prevented the server from fulfilling your request: Unable to parse connection string: 2001:db8:1000:1:f816:3eff:fe2a:f9c7:11211 (Disable debug mode to suppress these details.) (HTTP 500) (Request-ID: req-7c2bfd39-4b83 -462b-92c6-f75f7677c8e5) To reproduce scenario B: IPv6 address enclosed in brackets 1) Configure keystone according to http://docs.openstack.org/kilo/install-guide/install/apt/content/keystone-install.html 2) In section [memcache] in /etc/keystone/keystone.conf change servers = line: servers = [2001:db8:1000:1:f816:3eff:fe2a:f9c7]:11211,[2001:db8:1000:1:f816:3eff:fee9:9ce3]:11211,[2001:db8:1000:1:f816:3eff:fead:8f7f]:11211 3) Restart keystone/apache 4) Attempt to issue token: openstack --os-auth-url http://192.168.0.15:35357 --os-project-name admin --os-username admin --os-auth-type password token issue ERROR: openstack An unexpected error prevented the server from fulfilling your request: Unable to parse connection string: [2001:db8:1000:1:f816:3eff:fe2a:f9c7]:11211 (Disable debug mode to suppress these details.) (HTTP 500) (Request-ID: req- 869eb953-74af-4336-b3e1-dc3a417180f9) To reproduce scenario C: hostname that resolves to IPv6-only address 1) Configure keystone according to http://docs.openstack.org/kilo/install-guide/install/apt/content/keystone-install.html 2) In section [memcache] in /etc/keystone/keystone.conf change servers = line: servers = keystone-1:11211,keystone-2:11211,keystone-3:11211 3) Edit /etc/hosts: 2001:db8:1000:1:f816:3eff:fe2a:f9c7 keystone-1 2001:db8:1000:1:f816:3eff:fee9:9ce3 keystone-2 2001:db8:1000:1:f816:3eff:fead:8f7f keystone-3 3) Restart keystone/apache 4) Attempt to issue token: openstack --os-auth-url http://192.168.0.15:35357 --os-project-name admin --os-username admin --os-auth-type password token issue Password: ERROR: openstack Maximum lock attempts on _lockusertokens-30dbbe8174b24174a3a24d1ae554ab17 occurred. (Disable debug mode to suppress these details.) (HTTP 500) (Request-ID: req-efd53eae-4bcf-4fd9-bab2-dd4c86fb9798) Control test: 1) Configure keystone according to http://docs.openstack.org/kilo/install-guide/install/apt/content/keystone-install.html 2) In section [memcache] in /etc/keystone/keystone.conf change servers = line: servers = keystone-1:11211,keystone-2:11211,keystone-3:11211 3) Edit /etc/hosts: 192.168.0.15 keystone-1 192.168.0.14 keystone-2 192.168.0.16 keystone-3 3) Restart keystone/apache 4) Attempt to issue token: openstack --os-auth-url http://192.168.0.15:35357 --os-project-name admin --os-username admin --os-auth-type password token issue Password: ++--+ | Field | Value| ++--+ | expires| 2015-06-05T00:31:30Z
[Yahoo-eng-team] [Bug 1221805] Re: LDAP Assignment backend does not support all v3 APIs
The LDAP assignment is deprecated as of Kilo so I don't see any reason to allow implementers to use it more. ** 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/1221805 Title: LDAP Assignment backend does not support all v3 APIs Status in Keystone: Won't Fix Bug description: The LDAP assignment backend is missing support for several of the v3 APIs, for example: - Role Grant CRUD - GET /role_assignments Now that we have split identity, we need to decide how we maintain the LDAP assignment backend, i.e.: - Bring it up to full spec - Freeze as is - Depreciate it - etc. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1221805/+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 1219690] Re: save the run_tests.sh output to file
https://review.openstack.org/#/c/199343/ has been merged and run_tests.sh has been deleted. ** 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/1219690 Title: save the run_tests.sh output to file Status in Keystone: Won't Fix Bug description: When there are lots of failures, and it is useful to find the failure you concerned in the log file. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1219690/+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 1199536] Re: Move dict test matchers into testtools
Keystone no longer maintains those matchers so there isn't anything to fix anymore. The keystone/test/matcher.py module was removed in https://review.openstack.org/#/c/154242/ ** Changed in: keystone Status: Triaged = Invalid -- 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/1199536 Title: Move dict test matchers into testtools Status in Ironic: Triaged Status in Keystone: Invalid Status in OpenStack Compute (nova): Won't Fix Status in oslo-incubator: Won't Fix Status in testtools: Incomplete Status in Trove: Triaged Bug description: Reduce code duplication by pulling DictKeysMismatch, DictMismatch and DictMatches from glanceclient/tests/matchers.py into a library (e.g. testtools) To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1199536/+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 1418956] Re: Test utilities assume use of assignment api
We can reopen this if it becomes something bigger. Right now there's no need and some debate about why drivers shouldn't implement the whole API. ** 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/1418956 Title: Test utilities assume use of assignment api Status in Keystone: Won't Fix Bug description: Our test fixtures and v3 test utils call the assignment API under the hood to create assignments. This is normally absolutely fine, although for developers looking to replace the assignments engine with their own, such APIs might fail. While a fuller solution would be to allow the disabling of all existing assignments tests, a simple thing we can do to let out-of-tree experimentation to at least use our test fixtures/utils is not to error out if the assignment APIs return NotImplemented. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1418956/+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 1485694] Re: Keystone raises an exception when it receives incorrectly encoded parameters
** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Status: New = Confirmed ** Changed in: keystone Importance: Undecided = Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1485694 Title: Keystone raises an exception when it receives incorrectly encoded parameters Status in Keystone: Confirmed Status in keystone package in Ubuntu: Confirmed Bug description: The following command will cause an exception: $ curl -g -i -X GET http://localhost:35357/v3/users?name=nonexit%E8nt -H User-Agent: python-keystoneclient -H Accept: application/json -H X-Auth-Token: ADMIN This command works as expected: $ curl -g -i -X GET http://localhost:35357/v3/users?name=nonexit%C3%A8nt -H User-Agent: python-keystoneclient -H Accept: application/json -H X-Auth-Token: ADMIN The exception occurs fairly deep in the WebOb library while it is trying to parse the parameters our of the URL. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1485694/+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 1359995] Re: Tempest failed to delete user
No Keystone work here is needed.
** 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/1359995
Title:
Tempest failed to delete user
Status in devstack:
Fix Released
Status in Keystone:
Invalid
Status in tempest:
Invalid
Bug description:
check-tempest-dsvm-full failed on a keystone change. Here's the main log:
http://logs.openstack.org/73/111573/4/check/check-tempest-dsvm-full/c5ce3bd/console.html
The traceback shows:
File tempest/api/volume/test_volumes_list.py, line 80, in tearDownClass
File tempest/services/identity/json/identity_client.py, line 189, in
delete_user
Unauthorized: Unauthorized
Details: {error: {message: The request you have made requires
authentication. (Disable debug mode to suppress these details.), code: 401,
title: Unauthorized}}
So it's trying to delete the user and it gets unauthorized. Maybe the
token was expired or marked invalid for some reason.
There's something wrong here, but the keystone logs are useless for
debugging now that it's running in Apache httpd. The logs don't have
the request or result line, so you can't find where the request was
being made.
Also, Tempest should be able to handle the token being invalidated. It
should just get a new token and try with that.
To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1359995/+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 1268875] Re: Oslo migrate.py does not have functionality to compute path to `migrate_repo`s
No work for Keystone here. I believe the bug is saying that the shared lib doesn't have a feature we already have in Keystone. ** 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/1268875 Title: Oslo migrate.py does not have functionality to compute path to `migrate_repo`s Status in Keystone: Invalid Status in oslo.db: Triaged Bug description: Oslo migrate.py does not have functionality corresponding to `keystone.common.sql.migration.find_migrate_repo`, for example. Synchronization is impossible without this functionality because the functionality is required. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1268875/+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 1288916] Re: Race in db test cases
This has been hanging around for a long time and it still doesn't look
like there is anything to be done on the Keystone side.
** 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/1288916
Title:
Race in db test cases
Status in Keystone:
Invalid
Status in oslo-incubator:
Fix Released
Bug description:
As I understand it, this is a known issue that's being worked, but
it's failing on a pretty regular basis in the oslo-incubator gate so
I'm filing a bug to recheck against. The problem manifests as
something like the following:
2014-03-06 17:59:21.354 | FAIL:
tests.unit.db.sqlalchemy.test_sqlalchemy.MySQLTraditionalModeTestCase.test_string_too_long
2014-03-06 17:59:21.355 | tags: worker-1
2014-03-06 17:59:21.355 |
--
2014-03-06 17:59:21.355 | Empty attachments:
2014-03-06 17:59:21.356 | stderr
2014-03-06 17:59:21.356 | stdout
2014-03-06 17:59:21.356 |
2014-03-06 17:59:21.357 | pythonlogging:'': {{{INFO
[openstack.common.db.sqlalchemy.session] MySQL server mode set to TRADITIONAL}}}
2014-03-06 17:59:21.357 |
2014-03-06 17:59:21.357 | Traceback (most recent call last):
2014-03-06 17:59:21.358 | File
tests/unit/db/sqlalchemy/test_sqlalchemy.py, line 278, in setUp
2014-03-06 17:59:21.358 | self.test_table.create()
2014-03-06 17:59:21.358 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/schema.py,
line 616, in create
2014-03-06 17:59:21.359 | checkfirst=checkfirst)
2014-03-06 17:59:21.359 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/base.py,
line 1479, in _run_visitor
2014-03-06 17:59:21.359 | conn._run_visitor(visitorcallable, element,
**kwargs)
2014-03-06 17:59:37.780 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/base.py,
line 1122, in _run_visitor
2014-03-06 17:59:37.781 | **kwargs).traverse_single(element)
2014-03-06 17:59:37.781 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/sql/visitors.py,
line 122, in traverse_single
2014-03-06 17:59:37.782 | return meth(obj, **kw)
2014-03-06 17:59:37.782 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/ddl.py,
line 89, in visit_table
2014-03-06 17:59:37.782 |
self.connection.execute(schema.CreateTable(table))
2014-03-06 17:59:37.783 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/base.py,
line 662, in execute
2014-03-06 17:59:37.783 | params)
2014-03-06 17:59:37.783 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/base.py,
line 720, in _execute_ddl
2014-03-06 17:59:37.784 | compiled
2014-03-06 17:59:37.784 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/base.py,
line 874, in _execute_context
2014-03-06 17:59:37.784 | context)
2014-03-06 17:59:37.784 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/base.py,
line 1024, in _handle_dbapi_exception
2014-03-06 17:59:37.785 | exc_info
2014-03-06 17:59:37.785 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/util/compat.py,
line 196, in raise_from_cause
2014-03-06 17:59:37.785 | reraise(type(exception), exception, tb=exc_tb)
2014-03-06 17:59:37.786 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/base.py,
line 867, in _execute_context
2014-03-06 17:59:37.786 | context)
2014-03-06 17:59:37.786 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/sqlalchemy/engine/default.py,
line 324, in do_execute
2014-03-06 17:59:37.787 | cursor.execute(statement, parameters)
2014-03-06 17:59:37.787 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/MySQLdb/cursors.py,
line 205, in execute
2014-03-06 17:59:37.789 | self.errorhandler(self, exc, value)
2014-03-06 17:59:37.789 | File
/home/jenkins/workspace/gate-oslo-incubator-python26/.tox/py26/lib/python2.6/site-packages/MySQLdb/connections.py,
line 36, in defaulterrorhandler
2014-03-06 17:59:37.790 | raise errorclass, errorvalue
2014-03-06 17:59:37.790 | OperationalError: (OperationalError) (1050, Table
'__tmp__test__tmp__mode' already
[Yahoo-eng-team] [Bug 1436324] Re: Keystone is not HA with memcache as token persistence driver
memcached is not HA by design. This isn't really something we can fix in Keystone, other than to removed this backend. memcached should really only by used in situations where it is a cache and the application can run even with it shut off. ** 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/1436324 Title: Keystone is not HA with memcache as token persistence driver Status in OpenStack Identity (Keystone): Won't Fix Bug description: Keystone becomes extremely slow if one of memcached servers, used as token persistence driver, stops working. This happens because Keystone re-initializes memcache client on every call and memcache client loses information about dead servers and time until they are dead. To reproduce the issue: 1. Set up two memcached instances on, say, virtual machines 2. Set [token]driver=keystone.token.persistence.backends.memcache_pool.Token 3. Set [memcache]servers=192.168.56.101:11211,192.168.56.102:11211 (change ip to your own) 4. Break down one of the servers. By turning the server off for example 5. Try signing in in Horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1436324/+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 1295280] Re: Dependency Injection always injects optional after import
Optional dependencies are going away soon: https://review.openstack.org/#/c/162770/ ** 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/1295280 Title: Dependency Injection always injects optional after import Status in OpenStack Identity (Keystone): Won't Fix Bug description: Dependency Injection is currently always loading optional dependencies because they are registered in a _factories list on import, this list is never cleared. While in practice production wont see this issue, however, for test cases this is a broken mechanic. Tests cannot clear the _Factories list because import only occurs once. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1295280/+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 1218942] Re: Dependency resolution does not create objects on demand
We are in the process of removing our current DI implementation. ** Changed in: keystone Status: Confirmed = 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/1218942 Title: Dependency resolution does not create objects on demand Status in OpenStack Identity (Keystone): Won't Fix Bug description: The isssue is clearest with the circular dependncy code between identity and assignment, but we see it throughout the code base: one component that requires another component has to be sure that the dependency has been initialized prior to access. This form of Dependency Injection is not new. The general pattern followed by Spring etc is that the app has a two phase process. Dugin the first phase (early in the application) component register as fulfilling dependencies and what dependencies they require. Afte a certain point (once the source files have all been parsed) object instantiation can begin. THere is no deliberate instantiate all objects stage as you may end up creating objects that you do not need. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1218942/+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 1446834] [NEW] Project tree cycle checking logic is broken
Public bug reported: The keystone.resource.backends.sql.Resource.list_projects_in_subtree method tries to check for cycles in the project hierarchy [1]. It's doing it wrong. This was not caught because there are no tests for it because you can't actually create cycles through the API. There are two things we can do here: 1. Be satisfied that we don't allow cycles and remove the checks 2. Fix then and mock out the tests to fabricate cycles [1] https://github.com/openstack/keystone/blob/master/keystone/resource/backends/sql.py#L97 ** Affects: keystone Importance: Undecided Assignee: David Stanek (dstanek) Status: Confirmed ** Description changed: The keystone.resource.backends.sql.Resource.list_projects_in_subtree method tries to check for cycles in the project hierarchy. It's doing it wrong. This was not caught because there are no tests for it because you can't actually create cycles through the API. There are two things we can do here: 1. Be satisfied that we don't allow cycles and remove the checks 2. Fix then and mock out the tests to fabricate cycles + + Specific problems: + + bug1: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/resource/backends/sql.py#n97 + - not creating a set properly + + ug2: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/resource/backends/sql.py#n109 + - set.union returns a new set; should be set.update() -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1446834 Title: Project tree cycle checking logic is broken Status in OpenStack Identity (Keystone): Confirmed Bug description: The keystone.resource.backends.sql.Resource.list_projects_in_subtree method tries to check for cycles in the project hierarchy [1]. It's doing it wrong. This was not caught because there are no tests for it because you can't actually create cycles through the API. There are two things we can do here: 1. Be satisfied that we don't allow cycles and remove the checks 2. Fix then and mock out the tests to fabricate cycles [1] https://github.com/openstack/keystone/blob/master/keystone/resource/backends/sql.py#L97 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1446834/+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 1333712] Re: NotImplemented _for_groups functions on LDAP
Marking this as won't fix because this backend has been deprecated and this patch is technically a new feature and not a bug 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 Keystone. https://bugs.launchpad.net/bugs/1333712 Title: NotImplemented _for_groups functions on LDAP Status in OpenStack Identity (Keystone): Won't Fix Bug description: These functions are not implemented on assignment LDAP backend: - get_roles_for_groups - list_projects_for_groups - list_domains_for_groups To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1333712/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1395368] Re: ExternalNetworksTest[JSON, XML].test_delete_external_networks_with_floating_ip failures
This keeps failing for a few reviews including:
https://review.openstack.org/#/c/134993/
** 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/1395368
Title:
ExternalNetworksTest[JSON,XML].test_delete_external_networks_with_floating_ip
failures
Status in OpenStack Identity (Keystone) Middleware:
New
Status in OpenStack Neutron (virtual network service):
New
Status in Tempest:
Incomplete
Bug description:
I'm unsure as to the root cause (looking through the basic neutron,
nova api logs didn't show much usefulness around the times these
failed)...
Here is the full log and link though:
http://logs.openstack.org/51/136551/2/check/gate-tempest-dsvm-neutron-
src-taskflow-icehouse/8e0bb9f/
2014-11-22 18:50:53.315 | {1}
tempest.api.network.admin.test_external_network_extension.ExternalNetworksTestJSON.test_delete_external_networks_with_floating_ip
[0.984493s] ... FAILED
ft333.2:
tempest.api.network.admin.test_external_network_extension.ExternalNetworksTestXML.test_delete_external_networks_with_floating_ip_StringException:
pythonlogging:'': {{{
2014-11-22 18:54:54,689 2113 DEBUG[tempest.common.rest_client] Request
(ExternalNetworksTestXML:test_delete_external_networks_with_floating_ip): 201
POST http://127.0.0.1:9696/v2.0/networks 0.080s
Request - Headers: {'Content-Type': 'application/xml', 'Accept':
'application/xml', 'X-Auth-Token': 'omitted'}
Body: ?xml version=1.0 encoding=UTF-8?
network xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:router=http://docs.openstack.org/ext/neutron/router/api/v1.0;router:external
True/router:external/network
Response - Headers: {'status': '201', 'content-length': '805',
'connection': 'close', 'date': 'Sat, 22 Nov 2014 18:54:54 GMT', 'content-type':
'application/xml; charset=UTF-8', 'x-openstack-request-id':
'req-9d70cf16-d0ae-46e6-9f40-9c68cc50a2f0'}
Body: ?xml version='1.0' encoding='UTF-8'?
network xmlns=http://openstack.org/quantum/api/v2.0;
xmlns:provider=http://docs.openstack.org/ext/provider/api/v1.0;
xmlns:quantum=http://openstack.org/quantum/api/v2.0;
xmlns:router=http://docs.openstack.org/ext/neutron/router/api/v1.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;statusACTIVE/statussubnets
quantum:type=list /name /provider:physical_network xsi:nil=true
/admin_state_up
quantum:type=boolTrue/admin_state_uptenant_ida3451f42641c4a3ab319253134e5a036/tenant_idprovider:network_typelocal/provider:network_typerouter:external
quantum:type=boolTrue/router:externalshared
quantum:type=boolFalse/sharedid0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/idprovider:segmentation_id
xsi:nil=true //network
2014-11-22 18:54:54,789 2113 DEBUG[tempest.common.rest_client] Request
(ExternalNetworksTestXML:test_delete_external_networks_with_floating_ip): 201
POST http://127.0.0.1:9696/v2.0/subnets 0.098s
Request - Headers: {'Content-Type': 'application/xml', 'Accept':
'application/xml', 'X-Auth-Token': 'omitted'}
Body: ?xml version=1.0 encoding=UTF-8?
subnet xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;ip_version
4/ip_versionnetwork_id
0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/network_idcidr
10.100.0.0/28/cidrgateway_ip 10.100.0.1/gateway_ip/subnet
Response - Headers: {'status': '201', 'content-length': '729',
'connection': 'close', 'date': 'Sat, 22 Nov 2014 18:54:54 GMT', 'content-type':
'application/xml; charset=UTF-8', 'x-openstack-request-id':
'req-4f27ac74-c53f-4dd7-bd90-7bb217c82626'}
Body: ?xml version='1.0' encoding='UTF-8'?
subnet xmlns=http://openstack.org/quantum/api/v2.0;
xmlns:quantum=http://openstack.org/quantum/api/v2.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;name /enable_dhcp
quantum:type=boolTrue/enable_dhcpnetwork_id0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/network_idtenant_ida3451f42641c4a3ab319253134e5a036/tenant_iddns_nameservers
quantum:type=list
/allocation_poolsallocation_poolstart10.100.0.2/startend10.100.0.14/end/allocation_pool/allocation_poolshost_routes
quantum:type=list /ip_version
quantum:type=int4/ip_versiongateway_ip10.100.0.1/gateway_ipcidr10.100.0.0/28/cidrid49d84272-4d7e-49fd-bf72-0dcf7c923db6/id/subnet
2014-11-22 18:54:54,877 2113 DEBUG[tempest.common.rest_client] Request
(ExternalNetworksTestXML:test_delete_external_networks_with_floating_ip): 201
POST http://127.0.0.1:9696/v2.0/floatingips 0.087s
Request - Headers: {'Content-Type': 'application/xml', 'Accept':
'application/xml', 'X-Auth-Token': 'omitted'}
Body: ?xml version=1.0 encoding=UTF-8?
floatingip
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;floating_network_id
0b8004ad-7e9d-4b8c-9de1-efa8177f6dfc/floating_network_id/floatingip
Response - Headers: {'status': '201', 'content-length': '560',
'connection':
[Yahoo-eng-team] [Bug 1383817] [NEW] Deprecate catalog replacements and whitelists
Public bug reported: Bug #1354208 reported a security flaw in the way that we performed substitution for catalog URLs. The immediate solution was to add a whitelist of config fields that are safe to use with substitution. The long term goal is to get rid of this feature and only allow tenant_id and user_id to be used for substitution. The first step for the Kilo release is to deprecate the feature. ** Affects: keystone Importance: High Assignee: David Stanek (dstanek) 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/1383817 Title: Deprecate catalog replacements and whitelists Status in OpenStack Identity (Keystone): In Progress Bug description: Bug #1354208 reported a security flaw in the way that we performed substitution for catalog URLs. The immediate solution was to add a whitelist of config fields that are safe to use with substitution. The long term goal is to get rid of this feature and only allow tenant_id and user_id to be used for substitution. The first step for the Kilo release is to deprecate the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1383817/+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 1377304] [NEW] Deleting endpoint group project fails
Public bug reported: Deleting a endpoint group project fails because the router specifies a controller method that doesn't exist. Adding this test highlights the error: def test_removing_an_endpoint_group_project(self): # create endpoint group endpoint_group_id = self._create_valid_endpoint_group( self.DEFAULT_ENDPOINT_GROUP_URL, self.DEFAULT_ENDPOINT_GROUP_BODY) # create an endpoint_group project url = self._get_project_endpoint_group_url( endpoint_group_id, self.default_domain_project_id) self.put(url) # remove the endpoint group project self.delete(url) self.get(url, expected_status=404) The `self.delete(url)` fails with the following error: AttributeError: 'ProjectEndpointGroupV3Controller' object has no attribute 'remove_endpo int_group_from_project' This returns a 500 error to the user for what should be a successful operation. ** Affects: keystone Importance: Medium Assignee: David Stanek (dstanek) Status: In Progress ** Tags: juno-rc-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1377304 Title: Deleting endpoint group project fails Status in OpenStack Identity (Keystone): In Progress Bug description: Deleting a endpoint group project fails because the router specifies a controller method that doesn't exist. Adding this test highlights the error: def test_removing_an_endpoint_group_project(self): # create endpoint group endpoint_group_id = self._create_valid_endpoint_group( self.DEFAULT_ENDPOINT_GROUP_URL, self.DEFAULT_ENDPOINT_GROUP_BODY) # create an endpoint_group project url = self._get_project_endpoint_group_url( endpoint_group_id, self.default_domain_project_id) self.put(url) # remove the endpoint group project self.delete(url) self.get(url, expected_status=404) The `self.delete(url)` fails with the following error: AttributeError: 'ProjectEndpointGroupV3Controller' object has no attribute 'remove_endpo int_group_from_project' This returns a 500 error to the user for what should be a successful operation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1377304/+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 1306559] Re: Fix python26 compatibility for RFCSysLogHandler
It looks like Keystone was fixed quite a while ago: https://review.openstack.org/#/c/87980/ ** Changed in: keystone Status: Incomplete = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1306559 Title: Fix python26 compatibility for RFCSysLogHandler Status in Cinder: Fix Committed Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Murano: Fix Released Status in OpenStack Neutron (virtual network service): Fix Committed Bug description: Currently used pattern https://review.openstack.org/#/c/63094/15/openstack/common/log.py (lines 471-479) will fail for Python 2.6.x. In order to fix the broken Python 2.6.x compatibility, old style explicit superclass method calls should be used instead. Here is an example of how to check this for Python v2.7 and v2.6: import logging.handlers print type(logging.handlers.SysLogHandler) print type(logging.Handler) Results would be: Python 2.7: type 'type', so super() may be used for RFCSysLogHandler(logging.handlers.SysLogHandler) Python 2.6:type 'classobj', so super() may *NOT* be used for RFCSysLogHandler(logging.handlers.SysLogHandler) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1306559/+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 1208734] Re: Drop openstack.common.exception
** Changed in: keystone Status: In Progress = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1208734 Title: Drop openstack.common.exception Status in OpenStack Telemetry (Ceilometer): Fix Released Status in Cinder: Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): Fix Released Status in The Oslo library incubator: Fix Released Status in Python client library for Neutron: Fix Committed Status in OpenStack Data Processing (Sahara, ex. Savanna): Fix Released Status in Taskflow for task-oriented systems.: Fix Released Bug description: The library openstack.common.exceptions is deprecated in Oslo and should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1208734/+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 1204964] Re: 'extra' columns are nullable
I'm pretty sure the only way for this to happen is for someone to muck with the database directly instead of going through the objects. So even if the column was not nullable there can still be data in there that would cause a failure. The implementation of JsonBlob handles an empty extra field properly. It effectively boils down to: from keystone.openstack.common import jsonutils jsonutils.dumps(None) 'null' ** Changed in: keystone Status: Triaged = 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/1204964 Title: 'extra' columns are nullable Status in OpenStack Identity (Keystone): Invalid Bug description: (keystone.common.wsgi): 2013-07-25 11:13:52,034 ERROR wsgi __call__ expected string or buffer Traceback (most recent call last): File /opt/stack/keystone/keystone/common/wsgi.py, line 240, in __call__ result = method(context, **params) File /opt/stack/keystone/keystone/token/controllers.py, line 80, in authenticate context, auth) File /opt/stack/keystone/keystone/token/controllers.py, line 259, in _authenticate_local user_id, tenant_id) File /opt/stack/keystone/keystone/token/controllers.py, line 373, in _get_project_roles_and_ref user_id, tenant_id) File /opt/stack/keystone/keystone/identity/core.py, line 127, in get_roles_for_user_and_project user_id, tenant_id) File /opt/stack/keystone/keystone/assignment/core.py, line 127, in get_roles_for_user_and_project group_role_list = _get_group_project_roles(user_id, project_ref) File /opt/stack/keystone/keystone/assignment/core.py, line 77, in _get_group_project_roles (user_id=user_id)) File /opt/stack/keystone/keystone/common/manager.py, line 44, in _wrapper return f(*args, **kw) File /opt/stack/keystone/keystone/identity/backends/sql.py, line 202, in list_groups_for_user return [self.get_group(x.group_id) for x in membership_refs] File /opt/stack/keystone/keystone/identity/backends/sql.py, line 250, in get_group return self._get_group(session, group_id).to_dict() File /opt/stack/keystone/keystone/identity/backends/sql.py, line 243, in _get_group ref = session.query(Group).get(group_id) File /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 775, in get return self._load_on_ident(key) File /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 2512, in _load_on_ident return q.one() File /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 2184, in one ret = list(self) File /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 2348, in instances rows = [process[0](row, None) for row in fetch] File /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/mapper.py, line 2120, in _instance populate_state(state, dict_, row, isnew, only_load_props) File /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/mapper.py, line 1974, in populate_state populator(state, dict_, row) File /usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/strategies.py, line 150, in fetch_col dict_[key] = row[col] File /usr/local/lib/python2.7/dist-packages/sqlalchemy/types.py, line 662, in process return process_value(value, dialect) File /opt/stack/keystone/keystone/common/sql/core.py, line 146, in process_result_value return jsonutils.loads(value) File /opt/stack/keystone/keystone/openstack/common/jsonutils.py, line 127, in loads return json.loads(s) File /usr/lib/python2.7/json/__init__.py, line 326, in loads return _default_decoder.decode(s) File /usr/lib/python2.7/json/decoder.py, line 366, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) TypeError: expected string or buffer (access): 2013-07-25 11:13:52,036 INFO core __call__ 192.168.122.94 - - [25/Jul/2013:15:13:52 +] POST http://192.168.122.94:5000/v2.0/tokens HTTP/1.0 400 88 (eventlet.wsgi.server): 2013-07-25 11:13:52,040 DEBUG wsgi write 192.168.122.94 - - [25/Jul/2013 11:13:52] POST /v2.0/tokens HTTP/1.1 400 225 0.038971 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1204964/+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 992214] Re: GET /tenants XSD schema validation fails
XML support is deprecated and slated for removal ** Changed in: keystone Status: Triaged = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/992214 Title: GET /tenants XSD schema validation fails Status in OpenStack Identity (Keystone): Won't Fix Bug description: Example (using sample data) (2012.1 tag) ?xml version=1.0 encoding=UTF-8? tenants xmlns=http://docs.openstack.org/identity/api/v2.0; tenant id=13a5829cc7b84750a60cdc71ee62f15f enabled=true name=admin/ tenant id=4ab192b13c2d4ab1956a8360ad844a6c enabled=true name=demo/ /tenants There are 2 errors, according to tenant.xsd: 1) description field is missing 2) id is not of type XSD:id (http://www.w3.org/TR/REC-xml-names/#NT-NCName) So, the above should have been something like: ?xml version=1.0 encoding=UTF-8? tenants xmlns=http://docs.openstack.org/identity/api/v2.0; tenant id=A13a5829cc7b84750a60cdc71ee62f15f enabled=true name=admin descriptionAdmin/description /tenant tenant id=B4ab192b13c2d4ab1956a8360ad844a6c enabled=true name=demo descriptionDemo/description /tenant /tenants To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/992214/+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 1360406] Re: Wrong return from list role assignments on KVS
Marked as WONT FIX since this isn't going to be in Juno and the KVS backends go away in Kilo[1]. 1. https://review.openstack.org/#/c/123122/ ** 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/1360406 Title: Wrong return from list role assignments on KVS Status in OpenStack Identity (Keystone): Won't Fix Bug description: List role assignments calls should return 'inherited_to_projects': 'projects' for an inherited assignment, as done by the SQL backend [1]. The KVS backend just ignore this information from the retrieved assignments. [1] https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L432 [2] https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/kvs.py#L279-L283 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1360406/+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 1270516] Re: XmlBodyMiddleware logic causes an unnecessary JSON to dict conversion
The XML middleware has been marked as deprecated so I don't see a lot of
work happening here.
** 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/1270516
Title:
XmlBodyMiddleware logic causes an unnecessary JSON to dict conversion
Status in OpenStack Identity (Keystone):
Won't Fix
Bug description:
The XmlBodyMiddleware converts request body from XML string to JSON
string and passes it on to the JsonBodyMiddleware next in chain.
Observe the following line in the XmlBodyMiddleware.process_request method:
request.body = jsonutils.dumps(
serializer.from_xml(request.body))
serializer.from_xml already converts the body to a python dict, but it
dumps it again as a JSON string to the request body.
Now, observe the following lines in JsonBodyMiddleware .process_request
method:
# Abort early if we don't have any work to do
params_json = request.body
if not params_json:
return
...
params = {}
for k, v in params_parsed.iteritems():
if k in ('self', 'context'):
continue
if k.startswith('_'):
continue
params[k] = v
...
request.environ[PARAMS_ENV] = params
The JsonBodyMiddleware converts JSON string to dict and then stores
the dict in request.environ (It does some additional filtering of the
dict before storing, but that doesn't look like it is JSON specific)
So, if the input request body has XML and the xml_body/json_body
middlware are used in the paste pipeline, the effective conversion is:
XML string = dict = JSON string = dict
This may induce a performance penalty (however minor it is) due to the
unnecessary JSON to dict conversion. The following is the required
conversion: XML string = dict
To achieve this, the following could be done:
Refactor the following lines from JsonBodyMiddlware.process_request method
and move it to a common module as a method:
params = {}
for k, v in params_parsed.iteritems():
if k in ('self', 'context'):
continue
if k.startswith('_'):
continue
params[k] = v
Then, call that method from XmlBodyMiddleware.process_request method
passing the serialized xml dict. Store the filtered dict as
request.environ[PARAMS_ENV]. Then, set the request.body to None.
With this change, the JsonBodyMiddlware next in chain would not process the
request due to the following initial check:
# Abort early if we don't have any work to do
params_json = request.body
if not params_json:
return
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1270516/+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 1262057] Re: XML middleware will try to convert everything even if it's not json
The XML middleware has been marked as deprecated so I don't see a lot of work happening here. ** Changed in: keystone Status: Incomplete = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1262057 Title: XML middleware will try to convert everything even if it's not json Status in OpenStack Identity (Keystone): Won't Fix Bug description: There are certain routes like /v2.0/certificates/ca that return PEM files that do not return the standard choice of JSON or XML data. If you request these routes with XML in the Accept field (like if you hit it with a browser) then the XML middleware will kick in and assume that, like other requests, it needs to load it as json then convert it to xml. This is obviously wrong. We should only be doing XML processing if we understand the content we are trying to convert, and it is better to return something that is not on the Accept list than return an error (in JSON no less). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1262057/+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 1366988] [NEW] Formatting error in debug logging
Public bug reported: When logging is set to the debug level revoke_token can fail when there is not audit_chain_id, but the token is supposed to be revoked by the chain. ** Affects: keystone Importance: Undecided Assignee: David Stanek (dstanek) 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/1366988 Title: Formatting error in debug logging Status in OpenStack Identity (Keystone): In Progress Bug description: When logging is set to the debug level revoke_token can fail when there is not audit_chain_id, but the token is supposed to be revoked by the chain. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366988/+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 1362309] [NEW] Creating an endpoint with an invalid service_id returns the wrong error code
Public bug reported: When creating or updating an endpoint with an invalid service_id specified the server returns a 404 instead of a 400. While it's true that the service can't be found, that's not the resource the client is attempting to access. This is misleading. ** Affects: keystone Importance: Undecided Assignee: David Stanek (dstanek) 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/1362309 Title: Creating an endpoint with an invalid service_id returns the wrong error code Status in OpenStack Identity (Keystone): In Progress Bug description: When creating or updating an endpoint with an invalid service_id specified the server returns a 404 instead of a 400. While it's true that the service can't be found, that's not the resource the client is attempting to access. This is misleading. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362309/+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 1355919] [NEW] By default when caching is on objects will be cached forever
Public bug reported: The `cache_time` setting for the assignments, catalogs and tokens is currently set to None by default. This means that if caching is enabled for one of those subsystems and the operator did not specify their own timeout the data will not automatically expire. We are doing invalidation when data changes, at least in some cases. I'm not sure that it's safe to say that anytime the data changes we are correctly invaliding the key. We should strive to do this as it's the right thing to do, but we should also have a default timeout so that things we miss will not slip through. I believe 10 minutes is a reasonable default for most things so I'll provide a patch with that as the value. When I read `cache_time` I see the only acceptable amount of time to accept stale data. Usually this is determined base on the information being cached, but we currently only have the ability to set this at the subsystem level. ** Affects: keystone Importance: Medium Assignee: David Stanek (dstanek) Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1355919 Title: By default when caching is on objects will be cached forever Status in OpenStack Identity (Keystone): Confirmed Bug description: The `cache_time` setting for the assignments, catalogs and tokens is currently set to None by default. This means that if caching is enabled for one of those subsystems and the operator did not specify their own timeout the data will not automatically expire. We are doing invalidation when data changes, at least in some cases. I'm not sure that it's safe to say that anytime the data changes we are correctly invaliding the key. We should strive to do this as it's the right thing to do, but we should also have a default timeout so that things we miss will not slip through. I believe 10 minutes is a reasonable default for most things so I'll provide a patch with that as the value. When I read `cache_time` I see the only acceptable amount of time to accept stale data. Usually this is determined base on the information being cached, but we currently only have the ability to set this at the subsystem level. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1355919/+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 1294437] Re: GET role by name OS-KSADM call not functional
** Changed in: keystone
Status: New = Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1294437
Title:
GET role by name OS-KSADM call not functional
Status in OpenStack Identity (Keystone):
Won't Fix
Bug description:
A get role by name call against adminurl returns all the roles instead
of the filtered role
GET /v2.0/OS-KSADM/roles?name=KeystoneServiceAdmin HTTP/1.1
Host: 10.127.101.67:35357
X-Auth-Token:
Content-Type: application/json
Accept-Encoding: gzip, deflate, compress
Accept: application/json
User-Agent: python-requests/2.2.1 CPython/2.7.4 Linux/3.13.0-17-generic
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 1624
Date: Wed, 19 Mar 2014 02:07:49 GMT
{roles: [{description: test description, name: delme6699871,
id: 0c388669b5f24b6b83e06a53132ac8f3}, {description: test
description, name: delme5826205, id:
13a0e7d803674798ba4d7162a687ee78}, {id:
1a5c8dae44f047a8ac972f0c5281f9a8, name: admin}, {description:
test description, name: delme2440856, id:
2ac7708dbabe495b8b521d522789ac69}, {description: test
description, name: delme6598029, id:
345941408ff14352852c6effeeafffd6}, {description: test
description, name: delme3997949, id:
6defa1fe084d475abefdba18bc16da7b}, {id:
7d07bbea97b040cf9aa70cd2c0519494, name: cls, cls: break},
{description: test description, name: delme8497993, id:
7e32e8d74fa44429975b66f2034e0e8f}, {description: test
description, name: delme3345843, id:
831fcc12e1c749eba4082e24f6e33c02}, {description: test
description, name: delme1401640, id:
85dbba78a47c4eedbbd3825febc15907}, {description: test
description, name: delme4184222, id:
93309675c7ff459b8d13bc1e1df3ee03}, {description: test
description, name: delme7697947, id:
9a473c7f75144da5b53799487d16d13d}, {enabled: True,
description: Default role for project membership, name:
_member_, id: 9fe2ff9ee4384b1894a90878d3e92bab}, {id:
e75fbe7b349c4200995026598768aae7, name: KeystoneAdmin}, {id:
eccfbb67d68f45d3bf3fba02017bd091, name: Member}, {description:
test description, name: delme3796526, id:
f72e90114945476eb081940e98c44976}, {id:
fc4fec9f825c44d3ba2a0501287d27e0, name: KeystoneServiceAdmin}]}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1294437/+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 1230360] Re: keystone-all --log-file logs to stdout
I think this is something that should be fixed in oslo if it needs to be fixed at all. There are a several different ways to configure logging and they don't play nicely together: There is log-file (and or log-dir), use_strerr and our logging.conf. There may be others that I don't know about. ** Also affects: oslo Importance: Undecided Status: New ** 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/1230360 Title: keystone-all --log-file logs to stdout Status in OpenStack Identity (Keystone): Invalid Status in Oslo - a Library of Common OpenStack Code: New Bug description: The help text for keystone-all says if I set --log-file then logging goes to the output file, otherwise it goes to stdout. But logging goes to stdout whether I set --log-file or not. Here's the output without --log-file: $ tools/with_venv.sh bin/keystone-all 2013-09-25 10:35:40.229 3406 INFO keystone.common.environment [-] Environment configured as: eventlet 2013-09-25 10:35:40.652 3406 WARNING keystone.token.provider [-] keystone.conf [signing] token_format is deprecated in favor of keystone.conf [token] provider 2013-09-25 10:35:40.747 3406 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:35357 2013-09-25 10:35:40.751 3406 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:5000 Here's the output with --log-file: $ tools/with_venv.sh bin/keystone-all --log-file /tmp/keystone-log1.txt 2013-09-25 10:35:54.747 3425 INFO keystone.common.environment [-] Environment configured as: eventlet 2013-09-25 10:35:55.168 3425 WARNING keystone.token.provider [-] keystone.conf [signing] token_format is deprecated in favor of keystone.conf [token] provider 2013-09-25 10:35:55.262 3425 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:35357 2013-09-25 10:35:55.266 3425 INFO keystone.common.environment.eventlet_server [-] Starting bin/keystone-all on 0.0.0.0:5000 I expected that when I used --log-file that there would be no ouput to stdout. Note that it wrote the same thing to the log file so maybe this is expected. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1230360/+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 1257396] Re: iso8601 DEBUG messages spam log
This was actually merged quite a while ago:
94731064 (Jamie Lennox 2013-12-03 12:33:28 +1000 167)
** Changed in: keystone
Status: In Progress = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1257396
Title:
iso8601 DEBUG messages spam log
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
Useless DEBUG messages are printed every time iso8601 parses a date:
(iso8601.iso8601): 2013-12-03 12:47:12,924 DEBUG iso8601 parse_date Parsed
2013-12-03T17:47:12Z into {'tz_sign': None, 'second_fraction': None, 'hour':
'17', 'tz_hour': None, 'month': '12', 'timezone': 'Z', 'second': '12',
'tz_minute': None, 'year': '2013', 'separator': 'T', 'day': '03', 'minute':
'47'} with default timezone iso8601.iso8601.Utc object at 0x1571cd0
(iso8601.iso8601): 2013-12-03 12:47:12,924 DEBUG iso8601 to_int Got '2013'
for 'year' with default None
(iso8601.iso8601): 2013-12-03 12:47:12,925 DEBUG iso8601 to_int Got '12' for
'month' with default None
(iso8601.iso8601): 2013-12-03 12:47:12,925 DEBUG iso8601 to_int Got '03' for
'day' with default None
(iso8601.iso8601): 2013-12-03 12:47:12,925 DEBUG iso8601 to_int Got '17' for
'hour' with default None
(iso8601.iso8601): 2013-12-03 12:47:12,925 DEBUG iso8601 to_int Got '47' for
'minute' with default None
(iso8601.iso8601): 2013-12-03 12:47:12,925 DEBUG iso8601 to_int Got '12' for
'second' with default None
The log level for iso8601 has been set to WARN in oslo-incubator:
https://github.com/openstack/oslo-incubator/commit/cbfded9c. This
change should be merged into keystone.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1257396/+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 1321042] [NEW] The newest Requests release causes unit tests to fail
Public bug reported: The latest version of requests changes the type of a Response's history. Unfortunately we have tests that type check so this minor change broke them. See https://github.com/kennethreitz/requests/commit/b8128d6 for the actual commit. ** Affects: keystone Importance: High Assignee: David Stanek (dstanek) Status: Confirmed ** Changed in: keystone Importance: Undecided = High ** Changed in: keystone Status: New = Confirmed ** Changed in: keystone Assignee: (unassigned) = David Stanek (dstanek) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1321042 Title: The newest Requests release causes unit tests to fail Status in OpenStack Identity (Keystone): Confirmed Bug description: The latest version of requests changes the type of a Response's history. Unfortunately we have tests that type check so this minor change broke them. See https://github.com/kennethreitz/requests/commit/b8128d6 for the actual commit. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1321042/+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 1292311] Re: 5 unicode unit test failures when building Debian package
I marked this an invalid as it wasn't a current bug in Keystone. The
problem was a Debian specific patch that looks to be a fix for an issue
we may have had in the past.
** Changed in: keystone
Status: New = 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/1292311
Title:
5 unicode unit test failures when building Debian package
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
==
FAIL:
keystone.tests.test_exception.ExceptionTestCase.test_invalid_unicode_string
--
Traceback (most recent call last):
_StringException: pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File /tmp/buildd/keystone-2014.1~b3/keystone/tests/test_exception.py,
line 100, in test_invalid_unicode_string
self.assertIn('%(attribute)', e.message)
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 327, in
assertIn
self.assertThat(haystack, Contains(needle))
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 406, in
assertThat
raise mismatch_error
MismatchError: '%(attribute)' not in 'Expecting to find xx in \xe7a va. The
server could not comply with the request since it is either malformed or
otherwise incorrect. The client is assumed to be in error.'
==
FAIL: keystone.tests.test_exception.ExceptionTestCase.test_unicode_string
--
Traceback (most recent call last):
_StringException: pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File /tmp/buildd/keystone-2014.1~b3/keystone/tests/test_exception.py,
line 92, in test_unicode_string
self.assertIn(u'\u2013', e.message)
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 327, in
assertIn
self.assertThat(haystack, Contains(needle))
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 404, in
assertThat
mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 454, in
_matchHelper
mismatch = matcher.match(matchee)
File /usr/lib/python2.7/dist-packages/testtools/matchers/_basic.py, line
285, in match
if self.needle not in matchee:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 29:
ordinal not in range(128)
==
FAIL:
keystone.tests.test_exception.SecurityErrorTestCase.test_invalid_unicode_string
--
Traceback (most recent call last):
_StringException: pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File /tmp/buildd/keystone-2014.1~b3/keystone/tests/test_exception.py,
line 100, in test_invalid_unicode_string
self.assertIn('%(attribute)', e.message)
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 327, in
assertIn
self.assertThat(haystack, Contains(needle))
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 406, in
assertThat
raise mismatch_error
MismatchError: '%(attribute)' not in 'Expecting to find xx in \xe7a va. The
server could not comply with the request since it is either malformed or
otherwise incorrect. The client is assumed to be in error.'
==
FAIL: keystone.tests.test_exception.SecurityErrorTestCase.test_unicode_string
--
Traceback (most recent call last):
_StringException: pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File /tmp/buildd/keystone-2014.1~b3/keystone/tests/test_exception.py,
line 92, in test_unicode_string
self.assertIn(u'\u2013', e.message)
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 327, in
assertIn
self.assertThat(haystack, Contains(needle))
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 404, in
assertThat
mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
File /usr/lib/python2.7/dist-packages/testtools/testcase.py, line 454, in
_matchHelper
mismatch = matcher.match(matchee)
File /usr/lib/python2.7/dist-packages/testtools/matchers/_basic.py, line
285,
[Yahoo-eng-team] [Bug 1305950] [NEW] Inconsistency with handling of unique constraints
Public bug reported: We have many unit tests (simple example[1]) that check to see that indexes are case insensitive. The problem is that our current implementation doesn't explicitly make the index case insensitive. That's left up the the RDBMS. This is problematic because in my testing I have seen different results: - SQLite - is case sensitive - MySQL - is case insensitive[2] - PostgreSQL - is case sensitive My goal was to get the unit tests working on MySQL/PostgreSQL, so I would like to figure out a direction. Should we drop those tests and leave it up to the environment? It's also possible to get SQLAlchemy create the proper index. I've never done it, but I'm sure it's possible. [references] 1. http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_backend.py#n1791 2. http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html ** 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/1305950 Title: Inconsistency with handling of unique constraints Status in OpenStack Identity (Keystone): New Bug description: We have many unit tests (simple example[1]) that check to see that indexes are case insensitive. The problem is that our current implementation doesn't explicitly make the index case insensitive. That's left up the the RDBMS. This is problematic because in my testing I have seen different results: - SQLite - is case sensitive - MySQL - is case insensitive[2] - PostgreSQL - is case sensitive My goal was to get the unit tests working on MySQL/PostgreSQL, so I would like to figure out a direction. Should we drop those tests and leave it up to the environment? It's also possible to get SQLAlchemy create the proper index. I've never done it, but I'm sure it's possible. [references] 1. http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_backend.py#n1791 2. http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1305950/+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 1297922] [NEW] Internationalization is broken when using httpd/keystone.py
Public bug reported: This was first mentioned on IRC last night: gyee | yes, running under apache yield a bunch warnings related to _(). I still need more detail on this exception. I setup a devstack to test and noticed that we are not setting things up to be lazily translated. This means that all messages will be translated to the default locale. If messages are translated lazily the messages being returned to users would be translated based on the language specified in the HTTP headers. ** 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/1297922 Title: Internationalization is broken when using httpd/keystone.py Status in OpenStack Identity (Keystone): New Bug description: This was first mentioned on IRC last night: gyee | yes, running under apache yield a bunch warnings related to _(). I still need more detail on this exception. I setup a devstack to test and noticed that we are not setting things up to be lazily translated. This means that all messages will be translated to the default locale. If messages are translated lazily the messages being returned to users would be translated based on the language specified in the HTTP headers. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1297922/+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 1260495] Re: Setting autodoc_tree_index_modules makes documentation builds fail
Adding Keystone to make sure we update our code to use this when committed and remove the temporary extension. ** Also affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1260495 Title: Setting autodoc_tree_index_modules makes documentation builds fail Status in OpenStack Identity (Keystone): New Status in Python Build Reasonableness: New Bug description: The arguments originally being passed into sphinx.apidoc specified '.' as the path to index. Unfortunately this includes the setup.py module. Sphinx dies while trying to process the setup.rst likely because the setup.py module calls setuptools.setup() when imported causing some sort of recursion. The final result is something like: 2013-12-08 21:08:12.088 | reading sources... [ 80%] api/setup 2013-12-08 21:08:12.100 | /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'setup_requires' 2013-12-08 21:08:12.101 | warnings.warn(msg) 2013-12-08 21:08:12.102 | /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'pbr' 2013-12-08 21:08:12.102 | warnings.warn(msg) 2013-12-08 21:08:12.103 | usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] 2013-12-08 21:08:12.103 |or: setup.py --help [cmd1 cmd2 ...] 2013-12-08 21:08:12.104 |or: setup.py --help-commands 2013-12-08 21:08:12.104 |or: setup.py cmd --help 2013-12-08 21:08:12.104 | 2013-12-08 21:08:12.105 | error: invalid command 'build_sphinx' 2013-12-08 21:08:12.622 | ERROR: InvocationError: '/home/jenkins/workspace/gate-keystone-docs/.tox/venv/bin/python setup.py build_sphinx' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1260495/+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
