[Yahoo-eng-team] [Bug 1676925] [NEW] db_sync --expand may run downtime-incurring operations
Public bug reported:
In discussing a fix for bug 1615014 with Richard, we realized that
running:
keystone-manage db_sync --expand
... automatically runs legacy (offline) migrations *specifically* when
upgrading from Mitaka->Newton. Therefore, we don't technically support
zero-downtime, rolling upgrades for Mitaka->Newton, despite having all
the rolling upgrade commands available in Newton.
Therefore, all of the following migration paths are effectively
identical in Mitaka->Newton upgrades, in that they all involve
destructive migrations downtime in the first step:
Migration path A:
keystone-manage db_sync # downtime-incurring operations normally occur
here
Migration path B:
keystone-manage db_sync # downtime-incurring operations normally occur here
keystone-manage db_sync --expand # this becomes a no-op
keystone-manage db_sync --migrate # this becomes a no-op
keystone-manage db_sync --contract # this becomes a no-op
Migration path C:
keystone-manage db_sync --expand # downtime-incurring operations only occur
here in Mitaka->Newton
keystone-manage db_sync --migrate
keystone-manage db_sync --contract # downtime-incurring operations normally
occur here
Migration path A is required for migrations up until Liberty->Mitaka,
and is still supported in Ocata and beyond. Migration path B works, but
there is no reason to recommend this path. Migration path C is
recommended for Newton->Ocata upgrades and beyond.
** Affects: keystone
Importance: Low
Assignee: Dolph Mathews (dolph)
Status: Triaged
** Tags: documentation upgrades
** Changed in: keystone
Status: New => Triaged
--
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/1676925
Title:
db_sync --expand may run downtime-incurring operations
Status in OpenStack Identity (keystone):
Triaged
Bug description:
In discussing a fix for bug 1615014 with Richard, we realized that
running:
keystone-manage db_sync --expand
... automatically runs legacy (offline) migrations *specifically* when
upgrading from Mitaka->Newton. Therefore, we don't technically support
zero-downtime, rolling upgrades for Mitaka->Newton, despite having all
the rolling upgrade commands available in Newton.
Therefore, all of the following migration paths are effectively
identical in Mitaka->Newton upgrades, in that they all involve
destructive migrations downtime in the first step:
Migration path A:
keystone-manage db_sync # downtime-incurring operations normally
occur here
Migration path B:
keystone-manage db_sync # downtime-incurring operations normally occur here
keystone-manage db_sync --expand # this becomes a no-op
keystone-manage db_sync --migrate # this becomes a no-op
keystone-manage db_sync --contract # this becomes a no-op
Migration path C:
keystone-manage db_sync --expand # downtime-incurring operations only occur
here in Mitaka->Newton
keystone-manage db_sync --migrate
keystone-manage db_sync --contract # downtime-incurring operations normally
occur here
Migration path A is required for migrations up until Liberty->Mitaka,
and is still supported in Ocata and beyond. Migration path B works,
but there is no reason to recommend this path. Migration path C is
recommended for Newton->Ocata upgrades and beyond.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1676925/+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 1459402] Re: Conceptual overview of the Keystone service catalog
** Project changed: openstack-manuals => keystone ** Changed in: keystone Milestone: ocata => None ** Changed in: keystone Assignee: Alexandra Settle (alexandra-settle) => Dolph Mathews (dolph) -- 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/1459402 Title: Conceptual overview of the Keystone service catalog Status in OpenStack Identity (keystone): Confirmed Bug description: As a result of a cross-project design session on the service catalog [1] at the OpenStack Liberty design summit in Vancouver, I wrote a commentary on a few key aspects of the service catalog that would certainly find a better home if disseminated into relevant docs: http://dolphm.com/openstack-keystone-service-catalog/ [1] https://etherpad.openstack.org/p/service-catalog-cross-project- vancouver To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459402/+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 1647800] Re: keystone-manage bootstrap isn't completely idempotent
Marking this as Medium in mitaka since we didn't support zero-downtime upgrades then, but this is still an unexpected behavior of bootstrap that would potentially affect an upgrade process. ** Also affects: keystone/mitaka Importance: Undecided Status: New ** Changed in: keystone/mitaka Importance: Undecided => High ** Changed in: keystone/newton Importance: Undecided => High ** Changed in: keystone/mitaka Importance: High => Medium ** Changed in: keystone/mitaka Status: New => Confirmed ** Changed in: keystone/newton Status: New => 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/1647800 Title: keystone-manage bootstrap isn't completely idempotent Status in OpenStack Identity (keystone): Confirmed Status in OpenStack Identity (keystone) mitaka series: Confirmed Status in OpenStack Identity (keystone) newton series: Confirmed Bug description: The keystone-manage bootstrap command was designed to be idempotent. Most everything in the bootstrap command is wrapped with a try/except to handle cases where specific entities already exist (i.e. there is already an admin project or an admin user from a previous bootstrap run). This is important because bootstrap handles the creation of administrator-like things in order to "bootstrap" a deployment. If bootstrap wasn't idempotent, the side-effect of running it multiple times would be catastrophic. During an upgrade scenario, using OpenStack Ansible's rolling upgrade support [0], from stable/newton to master, I noticed a very specific case where bootstrap was not idempotent. Even if the admin user passed to bootstrap already exists, the command will still attempt to update it's password [1], even if the admin password hasn't changed. It does the same thing with the user's enabled property. This somehow creates a revocation event to be stored for that specific user [2]. As a result, all tokens for the user specified in the bootstrap command will be invalid once the upgrade happens, since OpenStack Ansible relies on `keystone-manage bootstrap` during the upgrade. This only affects the bootstrap user, but it can be considered a service interruption since it is being done during an upgrade. We could look into only updating the user's password, or enabled field, if and only if they have changed. In that case, a revocation event *should* be persisted since the bootstrap command is changing something about the account. In the case where there is no change in password or enabled status, tokens should still be able to be validated across releases. I have documented the upgrade procedure and process in a separate repository [3] [0] https://review.openstack.org/#/c/384269/ [1] https://github.com/openstack/keystone/blob/1c60b1539cf63bba79711e237df496dfa094b2c5/keystone/cmd/cli.py#L226-L232 [2] http://cdn.pasteraw.com/9gz9964mwufyw3f98rv1mv1hqxezpis [3] https://github.com/lbragstad/keystone-performance-upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1647800/+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 1647800] Re: keystone-manage bootstrap isn't completely idempotent
Marking this as High because the consequence is perceivable downtime during a zero-downtime upgrade. ** Also affects: keystone/newton 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/1647800 Title: keystone-manage bootstrap isn't completely idempotent Status in OpenStack Identity (keystone): Confirmed Status in OpenStack Identity (keystone) mitaka series: Confirmed Status in OpenStack Identity (keystone) newton series: Confirmed Bug description: The keystone-manage bootstrap command was designed to be idempotent. Most everything in the bootstrap command is wrapped with a try/except to handle cases where specific entities already exist (i.e. there is already an admin project or an admin user from a previous bootstrap run). This is important because bootstrap handles the creation of administrator-like things in order to "bootstrap" a deployment. If bootstrap wasn't idempotent, the side-effect of running it multiple times would be catastrophic. During an upgrade scenario, using OpenStack Ansible's rolling upgrade support [0], from stable/newton to master, I noticed a very specific case where bootstrap was not idempotent. Even if the admin user passed to bootstrap already exists, the command will still attempt to update it's password [1], even if the admin password hasn't changed. It does the same thing with the user's enabled property. This somehow creates a revocation event to be stored for that specific user [2]. As a result, all tokens for the user specified in the bootstrap command will be invalid once the upgrade happens, since OpenStack Ansible relies on `keystone-manage bootstrap` during the upgrade. This only affects the bootstrap user, but it can be considered a service interruption since it is being done during an upgrade. We could look into only updating the user's password, or enabled field, if and only if they have changed. In that case, a revocation event *should* be persisted since the bootstrap command is changing something about the account. In the case where there is no change in password or enabled status, tokens should still be able to be validated across releases. I have documented the upgrade procedure and process in a separate repository [3] [0] https://review.openstack.org/#/c/384269/ [1] https://github.com/openstack/keystone/blob/1c60b1539cf63bba79711e237df496dfa094b2c5/keystone/cmd/cli.py#L226-L232 [2] http://cdn.pasteraw.com/9gz9964mwufyw3f98rv1mv1hqxezpis [3] https://github.com/lbragstad/keystone-performance-upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1647800/+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 1630092] Re: Admin password reset should be exempt from password history validation
** Also affects: keystone/newton Importance: Undecided Status: New ** Changed in: keystone/newton Importance: Undecided => Medium -- 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/1630092 Title: Admin password reset should be exempt from password history validation Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) newton series: New Bug description: In Newton, we added password history validation for all password changes. However, for administrative password resets, we shouldn't validate against the end-user's password history. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1630092/+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 1623117] [NEW] Prevent keystone from serving requests when schema or data migrations are not up to date
Public bug reported: There are three scenarios during a rolling upgrade process where we could prevent operators from doing the "wrong thing" (doing things out of order): 1) Operators running code from the next release before `keystone-manage db_sync --expand` has been run: If you run the next release before --expand is run, then you'll surely end up with fatal query errors as columns and tables won't exist that the app thinks should exist. 2) (the scary one) Operators running code from the next release before `keystone-manage db_sync --migrate` has been run: If you run the next release before --migrate is run, then any number of different types of failures are possible due to unpopulated columns & tables, including a risk of data loss as the new release tries to update records that it perceives to be unpopulated, which might propagate to the legacy schema during UPDATE operations, for example. 3) Operators running code from the previous release after `keystone- manage db_sync --contract` has been run: As in case (1), this may result in fatal query errors, but also presents a risk of introducing data inconsistency, as the legacy schema might not have a "full understanding" of the new schema, as would be the case with additive schema changes. The legacy application would no longer have triggers to rely on, so consequences would mostly be dependent on the default values of columns, constraints, etc. The second case worries me, as it's the most likely scenario where operators might not realize what's going on until it's too late. To prevent all of these scenarios, I think the application should check at startup to ensure that the expand and data migration repositories both match a minimum value (specifically, the most recent migration in the application's respective repositories). Doing the same sort of check at startup for the contract repo would be more difficult, as it'd be entirely dependent on when you last upgraded (whether it be last stable/* release or master at any point), so I'd like to leave that out of scope here. ** Affects: keystone Importance: Medium Status: New ** Tags: upgrades ** Summary changed: - Prevent keystone from serving requests when schema is not up to date + Prevent keystone from serving requests when schema or data migrations are not up to date -- 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/1623117 Title: Prevent keystone from serving requests when schema or data migrations are not up to date Status in OpenStack Identity (keystone): New Bug description: There are three scenarios during a rolling upgrade process where we could prevent operators from doing the "wrong thing" (doing things out of order): 1) Operators running code from the next release before `keystone- manage db_sync --expand` has been run: If you run the next release before --expand is run, then you'll surely end up with fatal query errors as columns and tables won't exist that the app thinks should exist. 2) (the scary one) Operators running code from the next release before `keystone-manage db_sync --migrate` has been run: If you run the next release before --migrate is run, then any number of different types of failures are possible due to unpopulated columns & tables, including a risk of data loss as the new release tries to update records that it perceives to be unpopulated, which might propagate to the legacy schema during UPDATE operations, for example. 3) Operators running code from the previous release after `keystone- manage db_sync --contract` has been run: As in case (1), this may result in fatal query errors, but also presents a risk of introducing data inconsistency, as the legacy schema might not have a "full understanding" of the new schema, as would be the case with additive schema changes. The legacy application would no longer have triggers to rely on, so consequences would mostly be dependent on the default values of columns, constraints, etc. The second case worries me, as it's the most likely scenario where operators might not realize what's going on until it's too late. To prevent all of these scenarios, I think the application should check at startup to ensure that the expand and data migration repositories both match a minimum value (specifically, the most recent migration in the application's respective repositories). Doing the same sort of check at startup for the contract repo would be more difficult, as it'd be entirely dependent on when you last upgraded (whether it be last stable/* release or master at any point), so I'd like to leave that out of scope here. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1623117/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to :
[Yahoo-eng-team] [Bug 1618653] [NEW] Legacy migration repository still accepts new migrations
Public bug reported: Now that we have rolling upgrades in place, we should have a unit test in place to ensure that developers (and reviewers) do not land additional patches to the legacy migration repository and expect everything to continue working, as that would be akin to rewriting our migration history. ** Affects: keystone Importance: Medium Status: Triaged ** Tags: low-hanging-fruit upgrades ** Summary changed: - Legacy migration repository still accepts patches + Legacy migration repository still accepts new migrations -- 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/1618653 Title: Legacy migration repository still accepts new migrations Status in OpenStack Identity (keystone): Triaged Bug description: Now that we have rolling upgrades in place, we should have a unit test in place to ensure that developers (and reviewers) do not land additional patches to the legacy migration repository and expect everything to continue working, as that would be akin to rewriting our migration history. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1618653/+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 1615024] [NEW] Forbid invalid operations in expand, migrate, and contract repositories
Public bug reported: In the legacy migration repository, we've traditionally allowed any sort of database manipulation, including tables to be created, data to be migrated, columns to be dropped, etc. Recently, we introduced a constraint on those upgrades to prevent non-additive operations from occurring as a first step towards minimal downtime upgrades. The 3 new repositories allow us to have zero downtime upgrades, but come with their own constraints that we should enforce via tests. 1. The expand repo should only be allowed to create tables, columns, indexes, and triggers. It should not be allowed to INSERT, UPDATE, or DELETE any data. It should not be allowed to drop tables, columns, indexes, or triggers. 1. The migrate repo should only be allowed to INSERT, UPDATE, and DELETE data. It should not be allowed to create or drop tables, columns, indexes, or triggers. 1. The contract repo should only be allowed to drop tables, columns, indexes, and triggers. It should not be allowed to INSERT, UPDATE, or DELETE any data. It should not be allowed to create tables, columns, indexes, or triggers. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) Status: Triaged ** Tags: test-improvement upgrades ** Changed in: keystone Status: New => Triaged -- 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/1615024 Title: Forbid invalid operations in expand, migrate, and contract repositories Status in OpenStack Identity (keystone): Triaged Bug description: In the legacy migration repository, we've traditionally allowed any sort of database manipulation, including tables to be created, data to be migrated, columns to be dropped, etc. Recently, we introduced a constraint on those upgrades to prevent non-additive operations from occurring as a first step towards minimal downtime upgrades. The 3 new repositories allow us to have zero downtime upgrades, but come with their own constraints that we should enforce via tests. 1. The expand repo should only be allowed to create tables, columns, indexes, and triggers. It should not be allowed to INSERT, UPDATE, or DELETE any data. It should not be allowed to drop tables, columns, indexes, or triggers. 1. The migrate repo should only be allowed to INSERT, UPDATE, and DELETE data. It should not be allowed to create or drop tables, columns, indexes, or triggers. 1. The contract repo should only be allowed to drop tables, columns, indexes, and triggers. It should not be allowed to INSERT, UPDATE, or DELETE any data. It should not be allowed to create tables, columns, indexes, or triggers. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1615024/+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 1615020] [NEW] Test that expand, migrate, contract repos have the same number of steps
Public bug reported: To ensure that each of the 3 new migration repositories contain the same number of steps, we should introduce a test to catch developers attempting to introduce a new step to any one of the new repos, without introducing no-op steps to all of them. Upon failure, the test should explain to developers that they need to add no-op migrations to the other repositories, and the motivation for doing so (e.g. making it easy for us to prevent deployers from breaking their databases). ** Affects: keystone Importance: Low Status: Triaged ** Tags: test-improvement upgrades ** Summary changed: - Test that expand, migrate, contract migration repos have the same number of migrations + Test that expand, migrate, contract repos have the same number of steps -- 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/1615020 Title: Test that expand, migrate, contract repos have the same number of steps Status in OpenStack Identity (keystone): Triaged Bug description: To ensure that each of the 3 new migration repositories contain the same number of steps, we should introduce a test to catch developers attempting to introduce a new step to any one of the new repos, without introducing no-op steps to all of them. Upon failure, the test should explain to developers that they need to add no-op migrations to the other repositories, and the motivation for doing so (e.g. making it easy for us to prevent deployers from breaking their databases). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1615020/+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 1615014] [NEW] Prevent --expand, --migrate, --contract from being run out of order
Public bug reported: Currently, keystone does nothing to prevent an operator from running each step of the rolling migration process out of order. Theoretically, most migrations will fail if the table they're looking to drop does not exist, etc, but that might not always be the case. The transition to rolling migrations introduces a few expectations between the migration repositories that we should be able to enforce rather easily, given that all 3 of the new migration repos should always contain the same number of migration steps). 1. All legacy migrations need to be run before any --expand migrations are allow to run. 2. The version number of the --expand repo must be greater than or equal to the version number of the --migrate repo. 3. The version number of the --migrate repo must be greater than or equal to the version number of the --contract repo. I'd expect each command to abort with an error message if there are outstanding steps from the previous repository that had not been run. As a bit of a special case, db_sync --expand could (continue to) run the legacy repository automatically, but only if the legacy repository is guaranteed to be additive-only, as non-additive migrations should never be run by --expand (perhaps we should find the version number of the last non-additive migration and check the current state of the db will not result in that non-additive migration to be accidentally run. ** Affects: keystone Importance: Low Status: Triaged ** Tags: upgrades user-experience -- 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/1615014 Title: Prevent --expand, --migrate, --contract from being run out of order Status in OpenStack Identity (keystone): Triaged Bug description: Currently, keystone does nothing to prevent an operator from running each step of the rolling migration process out of order. Theoretically, most migrations will fail if the table they're looking to drop does not exist, etc, but that might not always be the case. The transition to rolling migrations introduces a few expectations between the migration repositories that we should be able to enforce rather easily, given that all 3 of the new migration repos should always contain the same number of migration steps). 1. All legacy migrations need to be run before any --expand migrations are allow to run. 2. The version number of the --expand repo must be greater than or equal to the version number of the --migrate repo. 3. The version number of the --migrate repo must be greater than or equal to the version number of the --contract repo. I'd expect each command to abort with an error message if there are outstanding steps from the previous repository that had not been run. As a bit of a special case, db_sync --expand could (continue to) run the legacy repository automatically, but only if the legacy repository is guaranteed to be additive-only, as non-additive migrations should never be run by --expand (perhaps we should find the version number of the last non-additive migration and check the current state of the db will not result in that non-additive migration to be accidentally run. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1615014/+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 1595468] Re: Cannot encode revokeTree object when mongo is configured as cache
Moved this to oslo.cache, since keystone.common.cache.backends.mongo:MongoCacheBackend moved to oslo_cache.backends.mongo:MongoCacheBackend. I'm guessing we need to add a third case to that method to attempt to pickle complex objects? ** Changed in: keystone Importance: Undecided => Medium ** Changed in: keystone Status: New => Triaged ** Project changed: keystone => oslo.cache -- 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/1595468 Title: Cannot encode revokeTree object when mongo is configured as cache Status in oslo.cache: Triaged Bug description: When you configure mongo as the cache subsystem for keystone, it fails to store the revoke tree in the cache. This is due that the basetransform only expects single types or dictionaries. def transform_incoming(self, son, collection): """Used while saving data to MongoDB.""" for (key, value) in list(son.items()): if isinstance(value, api.CachedValue): son[key] = value.payload # key is 'value' field here son['meta'] = value.metadata elif isinstance(value, dict): # Make sure we recurse into sub-docs son[key] = self.transform_incoming(value, collection) return son In mitaka this code has been sent to oslo_cache.mongo but the issue is still there As a result there is a 500 error on the response for validating a token. This is the exception I am getting 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi [req-9508d2e4-4e4c-4fd1-8daa-bc7c3456a320 - - - - -] Cannot encode object: 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 452, in __call__ 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi response = self.process_request(request) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/middleware/core.py", line 305, in process_request 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi auth_context = self._build_auth_context(request) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/middleware/core.py", line 193, in _build_auth_context 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi token_data=self.token_provider_api.validate_token(token_id)) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 190, in validate_token 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi self._is_valid_token(token) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 296, in _is_valid_token 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi self.check_revocation(token) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 230, in check_revocation 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi return self.check_revocation_v3(token) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 223, in check_revocation_v3 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi self.revoke_api.check_token(token_values) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/contrib/revoke/core.py", line 226, in check_token 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi if self._get_revoke_tree().is_revoked(token_values): 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/dogpile/cache/region.py", line 1040, in decorate 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi should_cache_fn) 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/dogpile/cache/region.py", line 651, in get_or_create 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi async_creator) as value: 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/dogpile/core/dogpile.py", line 158, in __enter__ 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi return self._enter() 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/dogpile/core/dogpile.py", line 98, in _enter 2016-06-23 06:42:13.248 30288 ERROR keystone.common.wsgi generated = self._enter_create(createdtime) 2016-06-23 06:42:13.248 30288 ERROR
[Yahoo-eng-team] [Bug 1585147] Re: If http & https proxy is enabled on system then openstack services wont work as expected.
The 503 is coming from an intermediary proxy (likely whatever you're using to implement HTTPS), not keystone (keystone is not capable of returning a 503). ** 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/1585147 Title: If http & https proxy is enabled on system then openstack services wont work as expected. Status in OpenStack Identity (keystone): Invalid Bug description: Hi, i am trying to setup multi node using mitaka version. if i enable Http and https proxy on controller node then i was not able to create any openstack services. steps to reproduce the error. 1. setup a controller node 2. edit hostname and hosts and add all ip address > 10.0.0.10 controller 3. setup proxy for http and https > export http_proxy='http://abc.com:8080/' > export https_proxy='http://abc.com:8080/' > export no_proxy='10.0.0.0/24' 4. export all tokens > export OS_TOKEN=ADMIN_TOKEN > export OS_URL=http://controller:35357/v3 > export OS_IDENTITY_API_VERSION=3 5. now try creating keystone services. > openstack service create --name keystone --description "OpenStack Identity" identity OUTPUT : Service Unavailable (HTTP 503) even i added no proxy to exclude controller ip from proxy but apache server is not serving eith proxy rules. 6. if we curl os_url : it always redirects to proxy server page. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1585147/+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 1575368] Re: Federation Unable to handle multiple groups
Our stable branch policy dictates that we don't backport features, and
an API-impacting one would be the first to be denied in review.
Sadly, it looks like a significant oversight in the original
implementation, though.
** 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/1575368
Title:
Federation Unable to handle multiple groups
Status in OpenStack Identity (keystone):
Invalid
Bug description:
I'm using OIDC federated authentication, I'm able to use the mapping json to
do ephemeral user authentication.
Following is my mapping json:
[
{
"local": [
{
"user": {
"name": "{0}"
},
"group": {
"id": "{1}"
},
"domain": {
"name": "default"
}
}
],
"remote": [
{
"type": "HTTP_OIDC_EMAIL"
},
{
"type": "HTTP_OIDC_GROUP"
},
{
"type" : "HTTP_OIDC_ISS",
"any_one_of": [
"https://myidp.cisco.com/oauth2;
]
}
]
}
]
and when tested with the keystone-mange mapping, I'm able to see multiple
groups properly.
output of Keystone-mapping verification.
{
"group_ids": [
"5207b97776914a6b9f99e1c985533863,23a70aa1af5f4439afb628a10f53ade3"
],
"user": {
"domain": {
"id": "Federated"
},
"type": "ephemeral",
"name": "kathu...@cisco.com"
},
"group_names": []
}
However, when the same flow is executed thru the OIDC I get the
following error message
{"error": {"message": "Group ['5207b97776914a6b9f99e1c985533863',
'23a70aa1af5f4439afb628a10f53ade3'] returned by mapping fed_mapping
was not found in the backend. (Disable debug mode to suppress these
details.)", "code": 500, "title": "Internal Server Error"}}
I looked into the util.py code and printed the groups that were coming
into the validate_groups_in_backend function.
validate_groups_in_backend
/opt/stack/keystone/keystone/contrib/federation/utils.py:258
2016-04-26 12:38:46.750572 25124 DEBUG keystone.contrib.federation.utils
[req-b54b5075-a4e5-46fc-a600-f8a07cfaf2cf - - - - -] printing group_ids list
[u"['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3']"]
validate_groups_in_backend
/opt/stack/keystone/keystone/contrib/federation/utils.py:259
2016-04-26 12:38:46.750704 25124 DEBUG keystone.contrib.federation.utils
[req-b54b5075-a4e5-46fc-a600-f8a07cfaf2cf - - - - -] printing group_id
['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3']
validate_groups_in_backend
/opt/stack/keystone/keystone/contrib/federation/utils.py:260
2016-04-26 12:38:47.092780 25124 WARNING keystone.common.wsgi
[req-b54b5075-a4e5-46fc-a600-f8a07cfaf2cf - - - - -] Group
['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3']
returned by mapping openam_mapping was not found in the backend. (Disable debug
mode to suppress these details.)
(END)
it looks like the list is formed incorrectly
[u"['5207b97776914a6b9f99e1c985533863', '23a70aa1af5f4439afb628a10f53ade3']"]
it should have been
[u'5207b97776914a6b9f99e1c985533863', u'23a70aa1af5f4439afb628a10f53ade3']
Thanks,
Krishna
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1575368/+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 1567025] Re: Can't use TokenManager. authenticate() with publicurl
Is there a patch up for this? It was filed under the "wrong" project, so
the bots would not have been able to link a patch.
** Project changed: keystone => python-keystoneclient
--
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/1567025
Title:
Can't use TokenManager. authenticate() with publicurl
Status in python-keystoneclient:
Triaged
Bug description:
See attached example.py for sample code and context.
Create a v2 client object:
* Use publicurl as the auth_url endpoint
* Use credentials that confer an admin role
Call client.tokens.authenticate() using any valid token/tenant_id.
The call fails when adminurl is unreachable.
Expectation is that publicurl would be used as the auth_url endpoint,
however ...
From https://github.com/openstack/python-
keystoneclient/blob/5a7f800e271695f21809d6251e91f6ac8e13ce23/keystoneclient/v2_0/tokens.py#L62-L69
# NOTE(jamielennox): try doing a regular admin query first. If there is
# no endpoint that can satisfy the request (eg an unscoped token) then
# issue it against the auth_url.
try:
token_ref = self._post(*args, **kwargs)
except exceptions.EndpointNotFound:
kwargs['endpoint_filter'] = {'interface': auth.AUTH_INTERFACE}
Our keystone adminurl is intentionally on a private network and
*unreachable* from where example.py is running (in a VM).
After quite a while, an exception is raised
(keystoneauth1.exceptions.ConnectFailure) and auth_url is never tried.
Meanwhile, a direct API call, skipping python-keystoneclient, works
fine:
* POST to publicurl, /v2/tokens, from the same location/VM
* Use X-Auth-Token of someone with an admin role
* Pass in the same valid token/tenant_id as before.
Additionally, a CLI call such as "nova list" (using the same
credentials and conferred admin role) also works.
To manage notifications about this bug go to:
https://bugs.launchpad.net/python-keystoneclient/+bug/1567025/+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 1572341] Re: Failed migration 90 -> 91 Can't DROP 'ixu_user_name_domain_id'
** Also affects: keystone/mitaka
Importance: Undecided
Status: New
** Changed in: keystone/mitaka
Importance: Undecided => High
--
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/1572341
Title:
Failed migration 90 -> 91 Can't DROP 'ixu_user_name_domain_id'
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) mitaka series:
New
Bug description:
Get the following error running DB migration when upgrading from kilo
-> mitaka
2016-04-20 09:31:37.560 10471 INFO migrate.versioning.api [-] 90 -> 91...
2016-04-20 09:31:37.822 10471 CRITICAL keystone [-] OperationalError:
(_mysql_exceptions.OperationalError) (1091, "Can't DROP
'ixu_user_name_domain_id'; check that column/key exists") [SQL: u'ALTER TABLE
user DROP INDEX ixu_user_name_domain_id']
2016-04-20 09:31:37.822 10471 ERROR keystone Traceback (most recent call
last):
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/usr/bin/keystone-manage", line 10, in
2016-04-20 09:31:37.822 10471 ERROR keystone sys.exit(main())
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/keystone/keystone/cmd/manage.py", line 47, in main
2016-04-20 09:31:37.822 10471 ERROR keystone cli.main(argv=sys.argv,
config_files=config_files)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/keystone/keystone/cmd/cli.py", line 992, in main
2016-04-20 09:31:37.822 10471 ERROR keystone CONF.command.cmd_class.main()
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/keystone/keystone/cmd/cli.py", line 371, in main
2016-04-20 09:31:37.822 10471 ERROR keystone
migration_helpers.sync_database_to_version(extension, version)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/keystone/keystone/common/sql/migration_helpers.py", line 210, in
sync_database_to_version
2016-04-20 09:31:37.822 10471 ERROR keystone _sync_common_repo(version)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/keystone/keystone/common/sql/migration_helpers.py", line 136, in
_sync_common_repo
2016-04-20 09:31:37.822 10471 ERROR keystone init_version=init_version,
sanity_check=False)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/migration.py",
line 79, in db_sync
2016-04-20 09:31:37.822 10471 ERROR keystone migration =
versioning_api.upgrade(engine, repository, version)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/api.py", line
186, in upgrade
2016-04-20 09:31:37.822 10471 ERROR keystone return _migrate(url,
repository, version, upgrade=True, err=err, **opts)
2016-04-20 09:31:37.822 10471 ERROR keystone File "",
line 2, in _migrate
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py",
line 160, in with_engine
2016-04-20 09:31:37.822 10471 ERROR keystone return f(*a, **kw)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/api.py", line
366, in _migrate
2016-04-20 09:31:37.822 10471 ERROR keystone schema.runchange(ver,
change, changeset.step)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/schema.py",
line 93, in runchange
2016-04-20 09:31:37.822 10471 ERROR keystone change.run(self.engine, step)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/script/py.py",
line 148, in run
2016-04-20 09:31:37.822 10471 ERROR keystone script_func(engine)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/keystone/keystone/common/sql/migrate_repo/versions/091_migrate_data_to_local_user_and_password_tables.py",
line 61, in upgrade
2016-04-20 09:31:37.822 10471 ERROR keystone
name='ixu_user_name_domain_id').drop()
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/changeset/constraint.py",
line 59, in drop
2016-04-20 09:31:37.822 10471 ERROR keystone
self.__do_imports('constraintdropper', *a, **kw)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/changeset/constraint.py",
line 32, in __do_imports
2016-04-20 09:31:37.822 10471 ERROR keystone run_single_visitor(engine,
visitorcallable, self, *a, **kw)
2016-04-20 09:31:37.822 10471 ERROR keystone File
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/changeset/databases/visitor.py",
line 85, in run_single_visitor
2016-04-20 09:31:37.822 10471 ERROR keystone fn(element, **kwargs)
2016-04-20 09:31:37.822 10471 ERROR keystone File
[Yahoo-eng-team] [Bug 1588927] Re: /v3/groups?name= bypasses group_filter for LDAP
** Also affects: keystone/mitaka Importance: Undecided Status: New ** Changed in: keystone/mitaka Status: New => In Progress ** Changed in: keystone/mitaka Importance: Undecided => Medium ** Changed in: keystone/mitaka Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- 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/1588927 Title: /v3/groups?name= bypasses group_filter for LDAP Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: In Progress Bug description: The same problem reported and fixed for users as https://bugs.launchpad.net/keystone/+bug/1577804 also exists for groups. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1588927/+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 1591022] [NEW] Transient test failure in test_v3_auth.TestAuthTOTP
Public bug reported: In 0.06% of my test runs, test_v3_auth.TestAuthTOTP fails with either: Traceback (most recent call last): File "/root/keystone/keystone/tests/unit/test_v3_auth.py", line 4904, in test_with_multiple_credential$ self.v3_create_token(auth_data, expected_status=http_client.CREATED) File "/root/keystone/keystone/tests/unit/test_v3.py", line 504, in v3_create_token expected_status=expected_status) File "/root/keystone/keystone/tests/unit/rest.py", line 212, in admin_request return self._request(app=self.admin_app, **kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 201, in _request response = self.restful_request(**kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 186, in restful_request **kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 90, in request **kwargs) File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 571, in request expect_errors=expect_errors, File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 636, in do_requ$ st self._check_status(status, res) File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 671, in _check_$ tatus "Bad response: %s (not %s)", res_status, status) webtest.app.AppError: Bad response: 401 Unauthorized (not 201) OR Traceback (most recent call last): File "/root/keystone/keystone/tests/unit/test_v3_auth.py", line 4961, in test_with_username_and_domain_ id self.v3_create_token(auth_data, expected_status=http_client.CREATED) File "/root/keystone/keystone/tests/unit/test_v3.py", line 504, in v3_create_token expected_status=expected_status) File "/root/keystone/keystone/tests/unit/rest.py", line 212, in admin_request return self._request(app=self.admin_app, **kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 201, in _request response = self.restful_request(**kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 186, in restful_request **kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 90, in request **kwargs) File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 571, in request expect_errors=expect_errors, File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 636, in do_reque st self._check_status(status, res) File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 671, in _check_s tatus "Bad response: %s (not %s)", res_status, status) webtest.app.AppError: Bad response: 401 Unauthorized (not 201) ** Affects: keystone Importance: Critical Assignee: werner mendizabal (nonameentername) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => werner mendizabal (nonameentername) ** Changed in: keystone Importance: Undecided => Critical ** Changed in: keystone Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1591022 Title: Transient test failure in test_v3_auth.TestAuthTOTP Status in OpenStack Identity (keystone): In Progress Bug description: In 0.06% of my test runs, test_v3_auth.TestAuthTOTP fails with either: Traceback (most recent call last): File "/root/keystone/keystone/tests/unit/test_v3_auth.py", line 4904, in test_with_multiple_credential$ self.v3_create_token(auth_data, expected_status=http_client.CREATED) File "/root/keystone/keystone/tests/unit/test_v3.py", line 504, in v3_create_token expected_status=expected_status) File "/root/keystone/keystone/tests/unit/rest.py", line 212, in admin_request return self._request(app=self.admin_app, **kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 201, in _request response = self.restful_request(**kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 186, in restful_request **kwargs) File "/root/keystone/keystone/tests/unit/rest.py", line 90, in request **kwargs) File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 571, in request expect_errors=expect_errors, File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 636, in do_requ$ st self._check_status(status, res) File "/root/keystone/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py", line 671, in _check_$ tatus "Bad response: %s (not %s)", res_status, status) webtest.app.AppError: Bad response: 401 Unauthorized (not 201) OR Traceback (most recent call last): File "/root/keystone/keystone/tests/unit/test_v3_auth.py", line 4961, in test_with_username_and_domain_ id self.v3_create_token(auth_data,
[Yahoo-eng-team] [Bug 1589993] Re: Murano cannot deploy with federated user
I imagine this will be addressed by (or nearly addressed by) having concrete role assignments for federated users in keystone: https://review.openstack.org/#/c/284943/ ** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Assignee: (unassigned) => Ron De Rose (ronald-de-rose) ** Changed in: keystone Importance: Undecided => Wishlist ** Changed in: keystone Status: New => Triaged -- 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/1589993 Title: Murano cannot deploy with federated user Status in OpenStack Identity (keystone): Triaged Status in Murano: New Bug description: Deploying with federated user throws an exception in murano-engine with: Exception Could not find role: 9fe2ff9ee4384b1894a90878d3e92bab (HTTP 404) The mentioned role is _member_ The full trace: 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/murano/common/engine.py", line 159, in execute 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine self._create_trust() 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/murano/common/engine.py", line 282, in _create_trust 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine self._session.token, self._session.project_id) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/murano/common/auth_utils.py", line 98, in create_trust 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine project=project) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneclient/v3/contrib/trusts.py", line 75, in create 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine **kwargs) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneclient/base.py", line 75, in func 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine return f(*args, **new_kwargs) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneclient/base.py", line 339, in create 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine self.key) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneclient/base.py", line 171, in _post 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine resp, body = self.client.post(url, body=body, **kwargs) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 179, in post 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine return self.request(url, 'POST', **kwargs) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 331, in request 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine resp = super(LegacyJsonAdapter, self).request(*args, **kwargs) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 98, in request 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine return self.session.request(url, method, **kwargs) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/positional/__init__.py", line 94, in inner 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine return func(*args, **kwargs) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine File "/usr/lib/python2.7/dist-packages/keystoneclient/session.py", line 420, in request 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine raise exceptions.from_response(resp, method, url) 2016-06-07 15:08:05.732 8194 ERROR murano.common.engine NotFound: Could not find role: 9fe2ff9ee4384b1894a90878d3e92bab (HTTP 404) (Request-ID: req-760d033b-e456-4915-b197-e450d4c8a405) Seems something wrong with creating a trust. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1589993/+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 1588860] Re: keystone-manage bootstrap cannot recover admin account
** Also affects: keystone/mitaka Importance: Undecided Status: New ** Changed in: keystone/mitaka Status: New => In Progress ** Changed in: keystone/mitaka Assignee: (unassigned) => Dolph Mathews (dolph) ** Changed in: keystone Importance: Undecided => Medium ** Changed in: keystone/mitaka Importance: Undecided => Medium -- 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/1588860 Title: keystone-manage bootstrap cannot recover admin account Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: In Progress Bug description: The keystone-manage bootstrap command is intended to supersede the admin_token middleware. However, one of the common use cases for the admin_token middleware was to provide a recovery mechanism for cloud operators that had accidentally disabled themselves or lost their password. However, even after attempting to "re-bootstrap" an existing admin with a known password (effectively performing a password reset), the admin is still not able to authenticate. The same is true if the admin was disabled. This was originally reported in #openstack-ansible by odyssey4me: [Fri 09:29] dolphm lbragstad is keystone-manage bootstrap meant to skip the bootstrap if there are already settings in place? what is the right way to fix up creds that are lost somehow for the keystone admin? [Fri 09:30] odyssey4me: bootstrap should be idempotent, but i don't think it'll change an admin's password if you specify something different [Fri 09:31] dolphm so the options are, I guess, to delete the admin account in the db or to use the auth_token middleware? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1588860/+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 1588860] [NEW] keystone-manage bootstrap cannot recover admin account
Public bug reported: The keystone-manage bootstrap command is intended to supersede the admin_token middleware. However, one of the common use cases for the admin_token middleware was to provide a recovery mechanism for cloud operators that had accidentally disabled themselves or lost their password. However, even after attempting to "re-bootstrap" an existing admin with a known password (effectively performing a password reset), the admin is still not able to authenticate. The same is true if the admin was disabled. This was originally reported in #openstack-ansible by odyssey4me: [Fri 09:29] dolphm lbragstad is keystone-manage bootstrap meant to skip the bootstrap if there are already settings in place? what is the right way to fix up creds that are lost somehow for the keystone admin? [Fri 09:30] odyssey4me: bootstrap should be idempotent, but i don't think it'll change an admin's password if you specify something different [Fri 09:31] dolphm so the options are, I guess, to delete the admin account in the db or to use the auth_token middleware? ** Affects: keystone Importance: Undecided Assignee: Dolph Mathews (dolph) Status: In Progress ** Affects: keystone/mitaka Importance: Undecided Status: New ** Tags: mitaka-backport-potential -- 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/1588860 Title: keystone-manage bootstrap cannot recover admin account Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) mitaka series: New Bug description: The keystone-manage bootstrap command is intended to supersede the admin_token middleware. However, one of the common use cases for the admin_token middleware was to provide a recovery mechanism for cloud operators that had accidentally disabled themselves or lost their password. However, even after attempting to "re-bootstrap" an existing admin with a known password (effectively performing a password reset), the admin is still not able to authenticate. The same is true if the admin was disabled. This was originally reported in #openstack-ansible by odyssey4me: [Fri 09:29] dolphm lbragstad is keystone-manage bootstrap meant to skip the bootstrap if there are already settings in place? what is the right way to fix up creds that are lost somehow for the keystone admin? [Fri 09:30] odyssey4me: bootstrap should be idempotent, but i don't think it'll change an admin's password if you specify something different [Fri 09:31] dolphm so the options are, I guess, to delete the admin account in the db or to use the auth_token middleware? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1588860/+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 1576315] [NEW] Critically fail on startup if fernet_setup has not been run
Public bug reported: As a result of the Fernet work session at the Newton design summit in Austin: Prior to making Fernet the default token provider, keystone should fail on startup if fernet_setup has not been run when fernet is also the configured token provider. Today, keystone will instead return a 500 trying to create or validate tokens. Failing on startup will give operators a bigger red flag about the work they need to do to use Fernet. ** Affects: keystone Importance: High Status: Confirmed ** Tags: fernet ** Changed in: keystone Status: New => 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/1576315 Title: Critically fail on startup if fernet_setup has not been run Status in OpenStack Identity (keystone): Confirmed Bug description: As a result of the Fernet work session at the Newton design summit in Austin: Prior to making Fernet the default token provider, keystone should fail on startup if fernet_setup has not been run when fernet is also the configured token provider. Today, keystone will instead return a 500 trying to create or validate tokens. Failing on startup will give operators a bigger red flag about the work they need to do to use Fernet. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1576315/+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 1536300] Re: Catalog response is inconsistent for domain scoped token
The example catalog for a domain scoped token looks correct to me: those are endpoints that do not presume tenancy in the URL. ** 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/1536300 Title: Catalog response is inconsistent for domain scoped token Status in OpenStack Identity (keystone): Invalid Bug description: Some of the endpoints include tenant information and if we use domain scoped token there is no tenant information. So the catalog doesn't have any entry for those services for domain scoped token which looks odd Since domain scoped token is used only by identity, the better apprach would be to include just identity catalog for domain scoped token. e.g Given below is the current response for domain scoped token. What is heat service's endpoint from this response? | heat | orchestration | | | nova | compute | | | cinder | volume| | || | internal: http://10.240.20.2:9090 | || | region1 | || | public: https://myhelion.test:9090 | || | region1 | || | admin: http://10.240.20.2:9090 | | ceilometer | metering | region1 | || | internal: http://10.240.20.2:8777/ | || | region1 | || | admin: http://10.240.20.2:8777/| || | region1 | || | public: https://myhelion.test:8777/| || | | | glance | image | region1 | || | public: https://myhelion.test:9292 | || | region1 | || | internal: http://10.240.20.2:9292 | || | region1 | || | admin: http://10.240.20.2:9292 | || | | To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1536300/+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 1541656] Re: OAuth Identity token gives Forbidden
This seems like a missing use case in openstackclient? If you give it an
existing token, why is it trying to rescope it? What is it trying to
rescope the token to?
** Also affects: python-openstackclient
Importance: Undecided
Status: 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1541656
Title:
OAuth Identity token gives Forbidden
Status in OpenStack Identity (keystone):
Incomplete
Status in python-openstackclient:
New
Bug description:
I have enabled OAuth1 in Keystone Kilo, then followed the flow described here:
https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-oauth1-ext.html#delegated-authentication-flow
Created a consumer, created a request token, authorized the request
token, exchanged it for an access token and finally obtained Identity
token out of the access token, which looks like:
HTTP/1.1 201 Created
Date: Thu, 04 Feb 2016 00:20:13 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Content-Length: 7982
X-Subject-Token: 5bae545dc72d499bb3ec2792c9e53cbd
Vary: X-Auth-Token
x-openstack-request-id: req-241f91a2-8bc5-44a0-8676-8f521e074475
Content-Type: application/json
{"token": {"methods": ["oauth1"], "roles": [{"id":
"9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}],
"expires_at": "2016-02-04T01:20:13.114596Z", "project": {"domain":
{"id": "default", "name": "Default"}, "id": ..skipped catalog,
etc. "OS-OAUTH1": {"access_token_id":
"f718a55aeae24fa1930b726cbd41b378", "consumer_id":
"979f33d9d2c54fd4ae9d5ed3c2c8f61b"}}}
Then when I try to use the token for example to list servers:
openstack --os-token 5bae545dc72d499bb3ec2792c9e53cbd --os-auth-url
https://host:5000/v3 --os-identity-api-version 3 --os-cacert
/etc/pki/trust/anchors/ca.pem --os-project-name Project1 server list
I get a surprising error:
Forbidden: You are not authorized to perform the requested action. (Disable
debug mode to suppress these details.) (HTTP 403) (Request-ID:
req-34f9098e-7f5d-45e6-95b6-6f4cac87159e)
After some debugging I found out that my call gets rejected at:
def token_authenticate(context, auth_payload, user_context, token_ref):
try:
# Do not allow tokens used for delegation to
# create another token, or perform any changes of
# state in Keystone. To do so is to invite elevation of
# privilege attacks
if token_ref.oauth_scoped or token_ref.trust_scoped:
raise exception.Forbidden()
What am I missing here? My token definitely is oauth_scoped and how am
I supposed to use this Identity token?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1541656/+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 1547031] Re: Can't distinguish users through openid login
Your mapping is unconditionally resulting in this behavior. See the
mapping documentation:
http://docs.openstack.org/developer/keystone/mapping_combinations.html
** 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/1547031
Title:
Can't distinguish users through openid login
Status in OpenStack Identity (keystone):
Invalid
Bug description:
Accrounding to the doc
(http://docs.openstack.org/developer/keystone/configure_federation.html), I
parse openid login in my devstack. and i have success login with google account.
but there is a problem, how can i distinguish users? I know all the
federation users are in one group, and the group is relate with a project. In
my devstack, all of users login through openid have the same project , and have
the same resource, when i create a resource and orther user login through
openid can also see the resource
I don't know whether somewhere i parsed is wrong, this is my mapping:
{
"local": [
{
"user": {
"name": "{3}",
"realname": "{2}",
"email": "{3}"
},
"group": {
"name": "demo",
"domain": {
"name": "Default"
}
}
}
],
"remote": [
{
"type": "HTTP_OIDC_SUB"
},
{
"type": "HTTP_OIDC_ISS"
},
{
"type": "HTTP_OIDC_NAME"
},
{
"type": "HTTP_OIDC_EMAIL"
}
]
}
devstack address: www.scorpio.ml
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1547031/+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 1516946] Re: keystone WSGI fail: ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option
I've run into this myself.
This is the result of using outdated WSGI startup scripts. As part of
your upgrade process, you must switch to the ones from the release
you're trying to deploy.
This is because keystone has refactored some responsibilities out of
those WSGI scripts, so your scripts are now redundant with what Keystone
is trying to do.
** Changed in: keystone
Status: Incomplete => 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/1516946
Title:
keystone WSGI fail: ArgsAlreadyParsedError: arguments already parsed:
cannot register CLI option
Status in OpenStack Identity (keystone):
Invalid
Status in puppet-keystone:
Invalid
Bug description:
Upgrade from Kilo to Liberty broke Keystone. Was running just fine as
WSGI on Apache with Kilo. Provisioned a new test cluster using puppet-
keystone master branch and getting the following error:
mod_wsgi (pid=28386): Target WSGI script '/usr/lib/cgi-bin/keystone/main'
cannot be loaded as Python module.
mod_wsgi (pid=28386): Exception occurred processing WSGI script
'/usr/lib/cgi-bin/keystone/main'.
Traceback (most recent call last):
File "/usr/lib/cgi-bin/keystone/main", line 25, in
application = wsgi_server.initialize_application(name)
File "/usr/lib/python2.7/dist-packages/keystone/server/wsgi.py", line 51,
in initialize_application
common.configure()
File "/usr/lib/python2.7/dist-packages/keystone/server/common.py", line 31,
in configure
config.configure()
File "/usr/lib/python2.7/dist-packages/keystone/common/config.py", line
1200, in configure
help='Do not monkey-patch threading system modules.'))
File "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 1824, in
__inner
result = f(self, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 1999, in
register_cli_opt
raise ArgsAlreadyParsedError("cannot register CLI option")
ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1516946/+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 1553149] Re: Instance in ERROR state due to ConnectFailure with keystone
Apache will refuse connections that it cannot assign to threads once MaxClients is exhausted, and if you're only running 10 threads, then I'm also guessing that your MaxClients is set to be less than the number of concurrent connections you're throwing at it. I'm closing this because this is just an Apache tuning issue. ** 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/1553149 Title: Instance in ERROR state due to ConnectFailure with keystone Status in OpenStack Identity (keystone): Invalid Bug description: When tried to run below rally scenario with concurrency 50, seeing issue with keystone. Can someone take a look? NOTE: Things will work fine with concurrency 10. 1. Create tenant, create network. 2. Create T1 router and set external network as gateway 3. Add network created in step 1 to T1 router 4. Launch instance(on kvm) in the private network and assign FIP. Ping FIP Setup: Single controller(32vCPU, 48GB RAM) 3 Network Nodes 100 ESX computes and 100 KVM computes Rally reports and logs attached to bug. Logs: 2016-03-01 01:26:34.699 DEBUG oslo_concurrency.lockutils [req-409c8595-d093-4cfe-8b98-b49d2c2accad ctx_rally_d6ed151ea67e4b78930c39c406fa64ed_user_0 ctx_rally_9526f233-a1b9-446b-beb6-d14dc678ff37_tenant_10] Releasing semaphore "refresh_cache-8c324106-c6dd-4b90-876d-e3cc33adfebf" from (pid=26585) lock /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:225 2016-03-01 01:26:34.704 ERROR nova.compute.manager [req-409c8595-d093-4cfe-8b98-b49d2c2accad ctx_rally_d6ed151ea67e4b78930c39c406fa64ed_user_0 ctx_rally_9526f233-a1b9-446b-beb6-d14dc678ff37_tenant_10] [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] Instance failed to spawn 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] Traceback (most recent call last): 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/compute/manager.py", line 2190, in _build_resources 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] yield resources 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/compute/manager.py", line 2036, in _build_and_run_instance 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] block_device_info=block_device_info) 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2758, in spawn 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] admin_pass=admin_password) 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 3251, in _create_image 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] content=files, extra_md=extra_md, network_info=network_info) 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/api/metadata/base.py", line 160, in __init__ 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] self.network_metadata = netutils.get_network_metadata(network_info) 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/virt/netutils.py", line 185, in get_network_metadata 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] if not network_info: 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/network/model.py", line 526, in __len__ 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] return self._sync_wrapper(fn, *args, **kwargs) 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/network/model.py", line 513, in _sync_wrapper 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] self.wait() 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] File "/opt/stack/nova/nova/network/model.py", line 545, in wait 2016-03-01 01:26:34.704 TRACE nova.compute.manager [instance: 8c324106-c6dd-4b90-876d-e3cc33adfebf] self[:] = self._gt.wait() 2016-03-01 01:26:34.704 TRACE
[Yahoo-eng-team] [Bug 1455582] Re: Hypervisor compromise may result in malicious trust creation
Closing this because bearer tokens, etc, are a well known weakness. ** 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/1455582 Title: Hypervisor compromise may result in malicious trust creation Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a hypervisor is compromised, and the hypervisor is a a Nova compute node, the end user now has access to every token that passes through that node. By default, a keystone token can be exchanged for another token. There is no restriction on scoping of the new token. A scoped token can be exchanged for an unscoped token, or a token scoped to a different project. We had set the default time limit for tokens down to 1 hour, to reduce the surface area of the attack. However, many workloads require a single token for the whole workload, and these workloads take more than one hour, so several installations have increased token lifespans back to the old value of 24 hours. A token can be used to change a password. If this is done, all tokens are revoked for the user. With the trust API, a user can set up a long term delegation that allows another user to perform an operation on their behalf. While tokens created via trusts are limited in what they can do, the limitations are only on things like change passwords or create a new token. Thus, if an attacker compromises a compute node and harvests tokens, the highest value attack for them is to automatically create a trust from the compromised user to some other account. This bypasses the time limitation of the token expiration, and will allow the attacker to perform operations on the users resources at the attackers convenience. Any site that is running a recent version of Heat would be expected to have many trusts set up from the customer user accounts to the Heat service user. Heat creates trusts using the users tokens, so we know this approach is not just theoretical, but actively used. This leaves a fairly obvious trail, in that a user can see all of the trusts created with the user as the trustor. Any trusts that do not have a Heat user as the trustee are suspect. It might even be possible to compromise Heat users, so even those should be audited. There are other ways that a harvested token can be abused, but the trust approach is the one I find the most worrysome, as it could be done as a "sleeper" agent. The same issues apply to the OAUTH1.0a extension. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1496998] Re: document fernet token provider is experimental
Closing this since we're moving in the opposite direction at this point. ** 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/1496998 Title: document fernet token provider is experimental Status in OpenStack Identity (keystone): Invalid Bug description: The fernet token provider is experimental. It's not passing the tempest tests that all other providers work with. - The documentation should say that ther fernet provider is experimental - If the deployer starts keystone with the fernet provider configured a warning message should be logged To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1496998/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1526976] Re: Any operation without token fails with internal server error for fernet token
** Also affects: keystone/liberty Importance: Undecided Status: New ** Changed in: keystone/liberty Importance: Undecided => Medium -- 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/1526976 Title: Any operation without token fails with internal server error for fernet token Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) liberty series: New Bug description: This bug is only for fernet token. Configure keystone to use fernet token. Call any operation without passing a X-Auth-Token. It reports 500 error. It should throw 401 e.g curl -X DELEETE $OS_AUTH_URL/v3/projects/https://bugs.launchpad.net/keystone/+bug/1526976/+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 1515485] Re: Heat CFN signals do not pass authorization
yanyao: What did the keystone logs say to indicate a relationship to
Fernet?
** Also affects: keystone
Importance: Undecided
Status: New
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Changed in: keystone
Status: New => Invalid
** Changed in: keystone/kilo
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/1515485
Title:
Heat CFN signals do not pass authorization
Status in OpenStack Identity (keystone):
Invalid
Status in OpenStack Identity (keystone) kilo series:
Incomplete
Status in openstack-ansible:
New
Bug description:
Note that this bug applies to the Kilo release. Master does not appear
to have this problem. I did not test liberty yet.
Heat templates that rely on CFN signals timeout because the API calls
that execute these signals return 403 errors. Heat signals, on the
other side, do work.
The problem was reported to me by Alex Cantu. I have verified it on
his multinode lab and have also reproduced on my own single-node
system hosted on a public cloud server. I suspect liberty/master
avoided the problem after Jesse and I reworked the Heat configuration
to use Keystone v3 the last day before the L release.
Example template, which can be executed in an AIO after running the
tempest playbook:
heat_template_version: 2013-05-23
resources:
wait_condition:
type: AWS::CloudFormation::WaitCondition
properties:
Handle: { get_resource: wait_handle }
Count: 1
Timeout: 600
wait_handle:
type: AWS::CloudFormation::WaitConditionHandle
my_instance:
type: OS::Nova::Server
properties:
image: cirros
flavor: m1.tiny
networks:
- network: "private"
user_data_format: RAW
user_data:
str_replace:
template: |
#!/bin/sh
echo "wc_notify"
curl -H "Content-Type:" -X PUT wc_notify --data-binary
'{"status": "SUCCESS"}'
params:
wc_notify: { get_resource: wait_handle }
This template should end very quickly, as it starts a cirros instance
that just sends a signal back to heat. But instead, it timeouts. The
user data script dumps the signal URL to the console log, if you then
try to send the signal manually you will get a 403. The original 403
can also be seen in the heat-api-cfn.log file. Here is the log
snippet:
2015-11-12 05:13:34.491 1862 INFO heat.api.aws.ec2token [-] Checking AWS
credentials..
2015-11-12 05:13:34.492 1862 INFO heat.api.aws.ec2token [-] AWS credentials
found, checking against keystone.
2015-11-12 05:13:34.493 1862 INFO heat.api.aws.ec2token [-] Authenticating
with http://172.29.236.100:5000/v3/ec2tokens
2015-11-12 05:13:34.533 1862 INFO heat.api.aws.ec2token [-] AWS
authentication failure.
2015-11-12 05:13:34.534 1862 INFO eventlet.wsgi.server [-]
10.0.3.181,172.29.236.100 - - [12/Nov/2015 05:13:34] "PUT
/v1/waitcondition/arn%3Aopenstack%3Aheat%3A%3A683acadf4d04489f8e991b44014e6fc1%3Astacks%2Fwc1%2Faa4083b6-ce6c-411f-9df9-d059abacf40c%2Fresources%2Fwait_handle?Timestamp=2015-11-12T05%3A12%3A27Z=HmacSHA256=65657d1021e24e49ba4fb6f217ca4a22=2=aCG%2FO04MNLzSlf5gIBGw1hMcC7bQzB3pZXVKzXLLNSo%3D
HTTP/1.1" 403 301 0.043961
For reference, the curl command to trigger the signal is: curl -H
"Content-Type:" -X PUT "
[Yahoo-eng-team] [Bug 1425108] Re: private _get_children() in sql backend doesn't support passing None values
https://review.openstack.org/#/c/158720/ (merged) closes bug 1425113. https://review.openstack.org/#/c/158731/ closes this bug, but was abandoned in favor of merging that patch into https://review.openstack.org/#/c/158372/ which has not merged. ** Changed in: keystone Status: Fix Released => In Progress ** Changed in: keystone Assignee: (unassigned) => Rodrigo Duarte (rodrigodsousa) -- 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/1425108 Title: private _get_children() in sql backend doesn't support passing None values Status in OpenStack Identity (keystone): In Progress Bug description: The _get_children() method [1] uses the "in_" clause, which doesn't support passing None as part of the list (it is not considered). Passing None is a valid situation if we want to query for all root projects in the hierarchy. [1] https://github.com/openstack/keystone/blob/master/keystone/resource/backends/sql.py#L86 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1425108/+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 1509683] Re: sometimes the sheepdogdriver doesn't work when copy_image_to_volume
Added cinder. ** Also affects: cinder 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/1509683 Title: sometimes the sheepdogdriver doesn't work when copy_image_to_volume Status in Cinder: New Status in OpenStack Identity (keystone): Incomplete Bug description: The sheepdog driver supports the function of copy_image_to_volume, but it can only write the image file to local sheepdog. In many cases, the cinder-volume is not depolyed on sheepdog node, so the copy_image_to_volume method doesn't work in those usage scenarios. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1509683/+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 1482773] Re: H405 violations: multi line docstring summary not separated with an empty line
** Also affects: keystoneauth Importance: Undecided Status: New ** Also affects: python-keystoneclient Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1482773 Title: H405 violations: multi line docstring summary not separated with an empty line Status in OpenStack Identity (keystone): In Progress Status in keystoneauth: New Status in keystonemiddleware: In Progress Status in python-keystoneclient: New Bug description: Keystone's tox.ini contains an "ignore" entry for H405. All violations of H405 should be fixed so that H405 can be removed from the ignore list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1482773/+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 1497461] Re: Fernet tokens fail for some users with LDAP identity backend
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Also affects: keystone/liberty
Importance: Undecided
Status: New
** Changed in: keystone/kilo
Status: New => Triaged
** Changed in: keystone/kilo
Importance: Undecided => High
** Changed in: keystone/liberty
Importance: Undecided => High
** Changed in: keystone/liberty
Status: New => In Progress
** Changed in: keystone/liberty
Assignee: (unassigned) => Eric Brown (ericwb)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1497461
Title:
Fernet tokens fail for some users with LDAP identity backend
Status in Keystone:
Fix Committed
Status in Keystone kilo series:
Triaged
Status in Keystone liberty series:
In Progress
Bug description:
The following bug fixed most situations where when using Fernet + LDAP
identify backend.
https://bugs.launchpad.net/keystone/+bug/1459382
However, some users have trouble, resulting in a UserNotFound exception in
the logs with a UUID. Here's the error:
2015-09-18 20:04:47.313 12979 WARNING keystone.common.wsgi [-] Could not find
user: 457269632042726f776e203732363230
So the issue is this. The user DN query + filter will return my user as:
CN=Eric Brown
72620,OU=PAO_Users,OU=PaloAlto_California_USA,OU=NALA,OU=SITES,OU=Engineering,DC=vmware,DC=com
Therefore, I have to use CN as the user id attribute. My user id
would therefore be "Eric Brown 72620". The fernet token_formatters.py
attempts to convert this user id into a UUID. And in my case that is
successful. It results in UUID of 457269632042726f776e203732363230.
Of course, a user id of 457269632042726f776e203732363230 doesn't exist
in LDAP, so as a result I get a UserNotFound. So I don't understand
why the convert_uuid_bytes_to_hex is ever used in the case of LDAP
backend.
For other users, the token_formatters.convert_uuid_bytes_to_hex()
raises a ValueError and everything works. Here's an example that
illustrates the behavior
>>> import uuid
>>> uuid_obj = uuid.UUID(bytes='Eric Brown 72620')
>>> uuid_obj.hex
'457269632042726f776e203732363230'
>>> import uuid
>>> uuid_obj = uuid.UUID(bytes='Your Mama')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/uuid.py", line 144, in __init__
raise ValueError('bytes is not a 16-char string')
ValueError: bytes is not a 16-char string
Here's the complete traceback (after adding some additional debug):
2015-09-18 20:04:47.312 12979 WARNING keystone.common.wsgi [-] EWB Traceback
(most recent call last):
File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 449,
in __call__
response = self.process_request(request)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line
238, in process_request
auth_context = self._build_auth_context(request)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line
218, in _build_auth_context
token_data=self.token_provider_api.validate_token(token_id))
File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line
198, in validate_token
token = self._validate_token(unique_id)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1013,
in decorate
should_cache_fn)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 640,
in get_or_create
async_creator) as value:
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158,
in __enter__
return self._enter()
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 98,
in _enter
generated = self._enter_create(createdtime)
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 149,
in _enter_create
created = self.creator()
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 612,
in gen_value
created_value = creator()
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1009,
in creator
return fn(*arg, **kw)
File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line
261, in _validate_token
return self.driver.validate_v3_token(token_id)
File
"/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/core.py",
line 258, in validate_v3_token
audit_info=audit_ids)
File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py",
line 441, in get_token_data
self._populate_user(token_data, user_id, trust)
File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py",
line 275, in _populate_user
user_ref = self.identity_api.get_user(user_id)
File "/usr/lib/python2.7/dist-packages/keystone/identity/core.py", line
342, in wrapper
return f(self, *args, **kwargs)
File
[Yahoo-eng-team] [Bug 1503712] Re: Error while deleting tenant in openstack Juno
We can use this ticket (I've added openstack-manuals to it), but I don't see anywhere on that page that it says to configure [trust] driver? [revoke] driver is mentioned, but it's value is correct. ** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: openstack-manuals 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/1503712 Title: Error while deleting tenant in openstack Juno Status in Keystone: Invalid Status in openstack-manuals: Incomplete Bug description: Hi, When I'm trying to delete project with keystone: keystone tenant-delete radomirProject I get this error in keystone.log 2015-10-07 16:28:49.132 2465 INFO eventlet.wsgi.server [-] 10.0.2.60 - - [07/Oct/2015 16:28:49] "POST /v2.0/tokens HTTP/1.1" 200 2494 0.091314 2015-10-07 16:28:49.154 2455 INFO eventlet.wsgi.server [-] 10.0.2.60 - - [07/Oct/2015 16:28:49] "GET /v2.0/tenants/12a876bf668240de8bff9d9869bb4334 HTTP/1.1" 200 263 0.011250 2015-10-07 16:28:49.182 2455 ERROR keystone.common.wsgi [-] 'Revoke' object has no attribute 'list_trusts_for_trustee' 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi Traceback (most recent call last): 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 223, in __call__ 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi result = method(context, **params) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 135, in delete_project 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi self.assignment_api.delete_project(tenant_id) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 112, in wrapper 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi result = f(*args, **kwargs) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/core.py", line 150, in delete_project 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi self._emit_invalidate_user_project_tokens_notification(payload) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 124, in wrapper 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi public=self.public) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 254, in _send_notification 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi notify_event_callbacks(service, resource_type, operation, payload) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 204, in notify_event_callbacks 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi cb(service, resource_type, operation, payload) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 516, in _delete_user_project_tokens_callback 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi project_id=project_id) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/persistence/core.py", line 167, in delete_tokens_for_user 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi for trust in self.trust_api.list_trusts_for_trustee(user_id): 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 74, in __getattr__ 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi f = getattr(self.driver, name) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi AttributeError: 'Revoke' object has no attribute 'list_trusts_for_trustee' 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1503712/+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 1503712] Re: Error while deleting tenant in openstack Juno
I'm going to assume you're on a stable/kilo or older release of Keystone, but I'll refer to master's setup.cfg as well. If you got that configuration value from documentation somewhere, then we need to re- open this as a doc bug. Basically, you've set the trust driver to be a revocation driver, which can't be expected to work. The only supported backend driver for trusts is keystone.trust.backends.sql.Trust: https://github.com/openstack/keystone/blob/stable/kilo/etc/keystone.conf.sample#L1733 https://github.com/openstack/keystone/blob/01b5a711c3056a54e138f73ff5f78ff1827655ea/setup.cfg#L155-L156 Whereas you have a value intended to be used as a [revoke] driver: https://github.com/openstack/keystone/blob/stable/kilo/etc/keystone.conf.sample#L1495 https://github.com/openstack/keystone/blob/01b5a711c3056a54e138f73ff5f78ff1827655ea/setup.cfg#L172 ** Changed in: keystone Status: Incomplete => Invalid ** Tags removed: kestone -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1503712 Title: Error while deleting tenant in openstack Juno Status in Keystone: Invalid Bug description: Hi, When I'm trying to delete project with keystone: keystone tenant-delete radomirProject I get this error in keystone.log 2015-10-07 16:28:49.132 2465 INFO eventlet.wsgi.server [-] 10.0.2.60 - - [07/Oct/2015 16:28:49] "POST /v2.0/tokens HTTP/1.1" 200 2494 0.091314 2015-10-07 16:28:49.154 2455 INFO eventlet.wsgi.server [-] 10.0.2.60 - - [07/Oct/2015 16:28:49] "GET /v2.0/tenants/12a876bf668240de8bff9d9869bb4334 HTTP/1.1" 200 263 0.011250 2015-10-07 16:28:49.182 2455 ERROR keystone.common.wsgi [-] 'Revoke' object has no attribute 'list_trusts_for_trustee' 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi Traceback (most recent call last): 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 223, in __call__ 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi result = method(context, **params) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 135, in delete_project 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi self.assignment_api.delete_project(tenant_id) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 112, in wrapper 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi result = f(*args, **kwargs) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/assignment/core.py", line 150, in delete_project 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi self._emit_invalidate_user_project_tokens_notification(payload) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 124, in wrapper 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi public=self.public) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 254, in _send_notification 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi notify_event_callbacks(service, resource_type, operation, payload) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 204, in notify_event_callbacks 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi cb(service, resource_type, operation, payload) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 516, in _delete_user_project_tokens_callback 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi project_id=project_id) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/persistence/core.py", line 167, in delete_tokens_for_user 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi for trust in self.trust_api.list_trusts_for_trustee(user_id): 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 74, in __getattr__ 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi f = getattr(self.driver, name) 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi AttributeError: 'Revoke' object has no attribute 'list_trusts_for_trustee' 2015-10-07 16:28:49.182 2455 TRACE keystone.common.wsgi To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1503712/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe :
[Yahoo-eng-team] [Bug 1498693] Re: unfriendly error when keystone tries to parse a URL
The keystoneclient session is trying to work with a null URL. Adding Jamie. ** Project changed: keystone => python-keystoneclient ** Changed in: python-keystoneclient Importance: Undecided => Medium ** Changed in: python-keystoneclient Status: New => Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1498693 Title: unfriendly error when keystone tries to parse a URL Status in python-keystoneclient: Triaged Bug description: Sorry about the vagueness, but here is a traceback that came up when I was helping someone debug. http://paste.openstack.org/show/465672/ It results in "AttributeError: 'NoneType' object has no attribute 'find'" which isn't too helpful. From what I could tell it was because either the token or identity URI was wrong. To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1498693/+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 1498556] [NEW] Reasonable assumptions concerning domain references
Public bug reported: There are 3 primary places where client can be configured to reference domains. The actual parameter names vary based on the configuration interface (a function's arguments, the env, CLI arguments, etc), but I'll use environment variables here for the sake of general familiarity: 1. OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME: Used for specifying the domain which owns the authenticating user. 2. OS_PROJECT_DOMAIN_ID and OS_PROJECT_DOMAIN_NAME: Used for specifying the domain which owns the desired project scope. 3. OS_DOMAIN_ID and OS_DOMAIN_NAME: Used for specifying the desired domain scope. On the service side, a "default domain" is created which, by default, looks like: id="default" name="Default" The default domain is exclusively used on the service-side for scoping v2 operations, which are not domain-aware, in the broader multi-domain namespace exposed by v3. The default domain's ID is mutable via configuration (CONF.identity.default_domain_id) and the domain name is mutable via the API (PATCH /v3/domains/default, for example). Generally, deployers should not have any reason to change the default domain ID from it's default value of "default". Both (1) and (2) refer to domains that provide context to other configuration options. In single domain deployments, or deployments wherein most users and projects exist in the "default domain", it would benefit the user experience to assume that the user's and project exist in the default domain. Specifically, this means that users have fewer (if any) additional configuration options to set when migrating from v2 to v3, easing adoption of v3 overall. Deployments that opt into more complex multi-domain arrangement are thus opting into consuming more complex configuration options on the client side (they must specify their non-default domains explicitly). On (3), these values should always default to null values, and no assumptions should ever be made about their values. If a non-null default were to be set, then that means that the client should always try to obtain a domain-scoped token which is almost never the intended behavior. There are three approaches to implementing this behavior. Two of them are obvious at a high level, but easily fragile. If OS_USER_DOMAIN_ID defaults to "default" to match the default CONF.identity.default_domain_id value, then whenever the user sets a OS_USER_DOMAIN_NAME, the OS_USER_DOMAIN_ID *must* be ignored in favor of using the specified domain name. This is a potentially unreliable behavior, as domain IDs are immutable and are thus more preferable as reliable references. If OS_USER_DOMAIN_NAME defaults to "Default" to match the default domain name value, then whenever the user sets a OS_USER_DOMAIN_ID, the OS_USER_DOMAIN_NAME *must* be ignored in favor of using the specified domain ID. This is a potentially unreliable behavior, as assuming that the default domain still has a default domain name of "Default" is fragile considering that it's mutable through the regular HTTP API (a deployer will inevitably change it, thus breaking the client's default behavior). This approach is fragile. The third option is a combination of the above two approaches, and must happen at the "last minute" before requests are issued to keystone (after all possible sources of configuration have been handled). That is, both OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME default to null values on the surface. When an actual HTTP request is built, normal configuration precedence takes place (for example, in a CLI client): 1) If an --os-user-domain-id is specified, then that is used, ignoring --os-user-domain-name, OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME. This is the most specific, reliable configuration option available. A warning could be issued about the ignored values being discarded to communicate this sequence of precedence. 2) If an --os-user-domain-name is specified, then that is used, ignoring OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME. 3) If an OS_USER_DOMAIN_ID, then that is used, ignoring OS_USER_DOMAIN_NAME. 4) If an OS_USER_DOMAIN_NAME, then that is used. 5) Else, assume the domain id="default". Everything above referencing a OS_USER_DOMAIN_ID + OS_USER_DOMAIN_NAME applies equally to OS_PROJECT_DOMAIN_ID + OS_PROJECT_DOMAIN_NAME. Note: a domain ID never needs to be specified in the same request as a domain name. Both are absolute references that cannot be confused due to namespace conflicts; the only difference between them is that domain IDs are system-defined + immutable and domain names are user-defined + mutable. And again, the server should never, ever assume domain IDs anywhere for any reason outside of v2 controllers assuming CONF.identity.default_domain_id as the explicit scope. v3 should never make any assumptions about domains: explicit is better than implicit here. ** Affects: keystone Importance: Medium Status: Triaged ** Affects: keystoneauth Importance: Medium
[Yahoo-eng-team] [Bug 1496222] Re: Requirements update breaks keystone install on 3'rd party CI systems
** Also affects: pbr 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/1496222 Title: Requirements update breaks keystone install on 3'rd party CI systems Status in Keystone: Incomplete Status in PBR: New Bug description: After this change: https://github.com/openstack/keystone/commit/db6c7d9779378a3a6a6c52c47fa0a303c9038508 systems that run clean devstack installs are now failing during stack.sh for: 2015-09-16 02:30:22.901 | Ignoring dnspython3: markers "python_version=='3.4'" don't match your environment 2015-09-16 02:30:23.035 | Obtaining file:///opt/stack/keystone 2015-09-16 02:30:23.464 | Complete output from command python setup.py egg_info: 2015-09-16 02:30:23.464 | error in setup command: Invalid environment marker: (python_version=='2.7' # MPL) 2015-09-16 02:30:23.464 | 2015-09-16 02:30:23.464 | 2015-09-16 02:30:23.465 | Command "python setup.py egg_info" failed with error code 1 in /opt/stack/keystone To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1496222/+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 1496220] Re: error in setup command: Invalid environment marker: (python_version=='2.7' # MPL)
This is neither a bug in keystone nor there a fix In Progress in keystone. ** Project changed: keystone => pbr ** Changed in: pbr Status: In Progress => 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/1496220 Title: error in setup command: Invalid environment marker: (python_version=='2.7' # MPL) Status in PBR: New Bug description: https://review.openstack.org/#/c/222000/ introduced a change in keystone/setup.cfg: --- @@ -24,7 +24,7 @@ packages = [extras] ldap = python-ldap>=2.4:python_version=='2.7' - ldappool>=1.0 # MPL + ldappool>=1.0:python_version=='2.7' # MPL memcache = python-memcached>=1.56 mongodb = - and CI failed with below error: -- " error in setup command: Invalid environment marker: (python_version=='2.7' # MPL)" Seems there's something wrong with comment handling. This is similar to https://bugs.launchpad.net/pbr/+bug/1487835 but it's not the same. we should remove the '# ... ' comments To manage notifications about this bug go to: https://bugs.launchpad.net/pbr/+bug/1496220/+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 1471289] Re: Fernet tokens and Federated Identities result in token scope failures
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Changed in: keystone/kilo
Importance: Undecided => High
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1471289
Title:
Fernet tokens and Federated Identities result in token scope failures
Status in Keystone:
Fix Released
Status in Keystone kilo series:
New
Bug description:
When keystone is configured to use fernet tokens and also configured
to be a SP for an external IDP then the token data received by nova
and other services appear to not contain the right information,
resulting in errors from nova-api-os-compute such as:
Returning 400 to user: Malformed request URL: URL's project_id
'69f5cff441e04554b285d7772630dec1' doesn't match Context's project_id
'None'
When keystone is switched to use uuid tokens, then everything works as
expected.
Further debugging of the request to the nova api shows:
'HTTP_X_USER_DOMAIN_NAME': None,
'HTTP_X_DOMAIN_ID': None,
'HTTP_X_PROJECT_DOMAIN_ID': None,
'HTTP_X_ROLES': '',
'HTTP_X_TENANT_ID': None,
'HTTP_X_PROJECT_DOMAIN_NAME': None,
'HTTP_X_TENANT': None,
'HTTP_X_USER': u'S-1-5-21-2917001131-1385516553-613696311-1108',
'HTTP_X_USER_DOMAIN_ID': None,
'HTTP_X_AUTH_PROJECT_ID': '69f5cff441e04554b285d7772630dec1',
'HTTP_X_DOMAIN_NAME': None,
'HTTP_X_PROJECT_NAME': None,
'HTTP_X_PROJECT_ID': None,
'HTTP_X_USER_NAME': u'S-1-5-21-2917001131-1385516553-613696311-1108'
Comparing the interaction of nova-api-os-compute with keystone for the
token validation between an internal user and a federated user, the
following is seen:
### federated user ###
2015-07-03 14:43:05.229 8103 DEBUG keystoneclient.session [-] REQ: curl -g -i
--insecure -X GET https://sp.testenvironment.local:5000/v3/auth/tokens -H
"X-Subject-Token: {SHA1}acff9b5962270fec270e693eacb4c987c335f5c5" -H
"User-Agent: python-keystoneclient" -H "Accept: application/json" -H
"X-Auth-Token: {SHA1}a6a8a70ae39c533379eccd51b6d253f264d59f14"
_http_log_request
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:193
2015-07-03 14:43:05.265 8103 DEBUG keystoneclient.session [-] RESP: [200]
content-length: 402 x-subject-token:
{SHA1}acff9b5962270fec270e693eacb4c987c335f5c5 vary: X-Auth-Token keep-alive:
timeout=5, max=100 server: Apache/2.4.7 (Ubuntu) connection: Keep-Alive date:
Fri, 03 Jul 2015 14:43:05 GMT content-type: application/json
x-openstack-request-id: req-df3dce71-3174-4753-b883-11eb31a67d7c
RESP BODY: {"token": {"methods": ["token"], "expires_at":
"2015-07-04T02:43:04.00Z", "extras": {}, "user": {"OS-FEDERATION":
{"identity_provider": {"id": "adfs-idp"}, "protocol": {"id": "saml2"},
"groups": []}, "id": "S-1-5-21-2917001131-1385516553-613696311-1108", "name":
"S-1-5-21-2917001131-1385516553-613696311-1108"}, "audit_ids":
["_a6BbQ6mSoGAY2u9NN0tFA"], "issued_at": "2015-07-03T14:43:04.00Z"}}
### internal user ###
2015-07-03 14:28:31.875 8103 DEBUG keystoneclient.session [-] REQ: curl -g -i
--insecure -X GET https://sp.testenvironment.local:5000/v3/auth/tokens -H
"X-Subject-Token: {SHA1}b9c6748d65a0492faa9862fabf0a56fd5fdd255d" -H
"User-Agent: python-keystoneclient" -H "Accept: application/json" -H
"X-Auth-Token: {SHA1}a6a8a70ae39c533379eccd51b6d253f264d59f14"
_http_log_request
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:193
2015-07-03 14:28:31.949 8103 DEBUG keystoneclient.session [-] RESP: [200]
content-length: 6691 x-subject-token:
{SHA1}b9c6748d65a0492faa9862fabf0a56fd5fdd255d vary: X-Auth-Token keep-alive:
timeout=5, max=100 server: Apache/2.4.7 (Ubuntu) connection: Keep-Alive date:
Fri, 03 Jul 2015 14:28:31 GMT content-type: application/json
x-openstack-request-id: req-6e0ed9f4-46c3-4c79-b444-f72963fc9503
RESP BODY: {"token": {"methods": ["password"], "roles": [{"id":
"9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}], "expires_at":
"2015-07-04T02:28:31.00Z", "project": {"domain": {"id": "default", "name":
"Default"}, "id": "0f491c8551c04cdc804a479af0bf13ec", "name": "demo"},
"catalog": "", "extras": {}, "user": {"domain": {"id": "default",
"name": "Default"}, "id": "76c8c3017c954d88a6ad69ee4cb656d6", "name": "test"},
"audit_ids": ["aAN_V0c6SLSI0Rm1hoScCg"], "issued_at":
"2015-07-03T14:28:31.00Z"}}
The data structures that come back from keystone are clearly quite
different.
### configuration environment ###
Ubuntu 14.04 OS
nova==12.0.0.0a1.dev51 # commit a4f4be370be06cfc9aa3ed30d2445277e832376f from
master branch
keystone==8.0.0.0a1.dev12 # commit a7ca13b687dd284f0980d768b11a3d1b52b4106e
from master branch
python-keystoneclient==1.6.1.dev19 # commit
d238cc9af4927d1092de207db978536d712af129 from master branch
python-openstackclient==1.5.1.dev11# commit
2d6bc8f4c38dbf997e3e71119f13f0328b4a8669 from master branch
[Yahoo-eng-team] [Bug 1484237] Re: token revocations not always respected when using fernet tokens
** Also affects: keystone/kilo Importance: Undecided Status: New ** Tags removed: kilo-backport-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/1484237 Title: token revocations not always respected when using fernet tokens Status in Keystone: Fix Committed Status in Keystone kilo series: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: A simple test that shows that fernet tokens are not always being invalidated. Simple test steps: 1) gets a token 2) deletes a token 3) tries to validate the deleted token When I run this in production on 10 tokens, I get about a 20% success rate on the token being detected as invalid, 80% of the time, keystone tells me the token is valid. I have validated that the token is showing in the revocation event table. I've tried a 5 second delay between the calls which did not change the behavior. My current script (below) will look for 204 and 404 to show failure and will wait forever. I've let it wait over 5 minutes, it seems to me that either keystone knows immediately that the token is invalid or not at all. I do not have memcache enabled on these nodes. The same test has a 100% pass rate with UUID tokens. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1484237/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1488208] Re: Revoking a role assignment revokes unscoped tokens too
** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone/kilo Importance: Undecided => Medium ** Tags removed: kilo-backport-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/1488208 Title: Revoking a role assignment revokes unscoped tokens too Status in Keystone: Fix Committed Status in Keystone kilo series: New Bug description: When you delete a role assignment using a user+role+project pairing, unscoped tokens between the user+project are unnecessarily revoked as well. In fact, two events are created for each role assignment deletion (one that is scoped correctly and one that is scoped too broadly). The test failure in https://review.openstack.org/#/c/216236/ illustrates this issue: http://logs.openstack.org/36/216236/1/check/gate-keystone- python27/3f44af1/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1488208/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1485553] Re: Does not report appropriate error if user ID is invaild
It sounds like the user experience issue here was fixed for both stable/kilo and master, then. I'm sure further refactoring could be done, but that doesn't need to be tracked in a bug. ** 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/1485553 Title: Does not report appropriate error if user ID is invaild Status in Keystone: Invalid Bug description: Here are the steps for repro 1. Create a Project 2.Create an User to a project 3. Create and add an role to project user 4. Try to revoke role by modifying project user ID commands: > openstack --insecure role list --user ad28fec1b20d4e54b004a9f0fadc7ab9 --project 627db9080f184b7d92408ff42c19a132 -+ IDNameProject User -+ 37cb4f08d18f496ba3a451fa5a8bf17a service project_nametest > curl --insecure https://keystone:35357/v3/projects/627db9080f184b7d92408ff42c19a132/users/ad28/roles/37cb4f08d18f496ba3a451fa5a8bf17a -X DELETE -H "X-Auth-Token:" -H "Content-Type: application/json" To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1485553/+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 1492951] Re: Juno keystone installation fail to import oslo_i18n
Moved this to oslo.i18n, but it sounds like openstack/requirements for stable/juno just need to be fixed to reflect the reality (that oslo.utils 1.4.0 requires oslo.i18n>=1.3.0). ** Project changed: keystone => oslo.i18n -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1492951 Title: Juno keystone installation fail to import oslo_i18n Status in oslo.i18n: In Progress Bug description: Test keystone installation on stable/juno recently, but failed to import module oslo_i18n + keystone-manage db_sync Traceback (most recent call last): File "/usr/bin/keystone-manage", line 30, in from keystone import cli File "/usr/lib/python2.7/site-packages/keystone/cli.py", line 22, in from keystone import assignment File "/usr/lib/python2.7/site-packages/keystone/assignment/__init__.py", line 15, in from keystone.assignment import controllers # noqa File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 26, in from keystone.common import controller File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 21, in from keystone.common import utils File "/usr/lib/python2.7/site-packages/keystone/common/utils.py", line 26, in from oslo.utils import strutils File "/usr/lib/python2.7/site-packages/oslo/utils/strutils.py", line 13, in from oslo_utils.strutils import * # noqa File "/usr/lib/python2.7/site-packages/oslo_utils/strutils.py", line 26, in from oslo_utils._i18n import _ File "/usr/lib/python2.7/site-packages/oslo_utils/_i18n.py", line 21, in import oslo_i18n ImportError: No module named oslo_i18n I checked global requirements for stable/juno http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/juno I found oslo.utils is below oslo.utils>=1.4.0,<1.5.0 # Apache-2.0 But oslo.i18n still below oslo.i18n>=1.0.0,<=1.3.1 # Apache-2.0 And from requirements of oslo.utils 1.4.0 http://git.openstack.org/cgit/openstack/oslo.utils/tree/requirements.txt?id=1.4.0 If we install oslo.utils version 1.4.0, it will require oslo.i18n >= 1.3.0 oslo.i18n>=1.3.0 # Apache-2.0 So if we only install oslo.i18n 1.0.0, it will output can not find module oslo_i18n To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.i18n/+bug/1492951/+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 1491926] Re: Remove padding from Fernet tokens
** Also affects: keystone/kilo Importance: Undecided Status: New ** Tags removed: kilo-backport-potential ** Changed in: keystone/kilo 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/1491926 Title: Remove padding from Fernet tokens Status in Keystone: Fix Committed Status in Keystone kilo series: New Bug description: In bug 1433372, we determined that we should percent encode Fernet tokens, because the padding characters (=) aren't considered URL safe by some RFCs. We also fail some tempest tests because clients sometimes decode or encode responses [0]. We should just remove the padding, that way clients don't have to worry about it. When we go to validate a token, we can determine what the padding is based on the length of the token: missing_padding = 4 - len(token) % 4 if missing_padding: token += b'=' * missing_padding [0] http://cdn.pasteraw.com/es3j52dpfgem4nom62e7vktk7g5u2j1 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1491926/+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
Leaving this as Incomplete unless someone can reproduce. ** Also affects: hacking Importance: Undecided Status: New ** Changed in: hacking Status: New => Incomplete ** 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/1490497 Title: pep8-incompliant filenames missing in gate console logs Status in hacking: Incomplete Status in Keystone: Incomplete 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 1479962] Re: Use extras for deployment-specific package requirements
devstack: - https://review.openstack.org/#/c/208584/ - https://review.openstack.org/#/c/208153/ ** Tags added: ldap ** Changed in: keystone Importance: Undecided => Low ** Also affects: devstack Importance: Undecided Status: New ** Changed in: devstack Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1479962 Title: Use extras for deployment-specific package requirements Status in devstack: In Progress Status in Keystone: In Progress Bug description: Keystone should use "extras" in setup.cfg for deployment-specific package requirements. One example is ldap. With this change, deployers can do something like `pip install keystone[ldap]` to install the packages required for ldap. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1479962/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1491817] Re: Revoking large token fails with "Request-URI Too Long (HTTP 414)"
According to Morgan, we're 40 days from dropping support for eventlet completely, so adding a new configuration option wouldn't provide much benefit. In addition, the length of PKI tokens is a widely known issue that has gone largely unaddressed (besides the introduction of PKIZ as a compressed alternative). Switching to either UUID or Fernet is the recommended workaround. ** Tags added: pki ** Tags added: eventlet ** Changed in: keystone Status: In Progress => Invalid ** Changed in: keystone Status: Invalid => 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/1491817 Title: Revoking large token fails with "Request-URI Too Long (HTTP 414)" Status in Keystone: Won't Fix Bug description: When running keystone in a eventlet based configuration in a setup with a lot of (long) endpoints defined I ran into tempest failures. It turns out that when it tries to revoke some keystone tokens in e.g. the api/identity/admin/v2/test_roles_negative.py tests the resulting request URI for the v2 API (DELETE /v2.0/tokens/) was too long for eventlet's defaults and there is currently no way to change that limit in keystone.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1491817/+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 1434034] Re: Disabling users & groups may not invalidate previously-issued tokens
Based on today's keystone meeting and the above comments, I've reduced the priority of this to Medium across the board and marked this as Won't Fix in Keystone. Although this is working as intended, we acknowledge that that intended behavior is poorly documented, and it seems an OSSN is the best route to rectify that. I'd be happy to work with whoever wants to write the OSSN - ping me in IRC (dolphm) or leave a comment here. ** Changed in: keystone Importance: Critical => Medium ** Changed in: keystone Status: In Progress => Won't Fix ** Changed in: keystone/juno Importance: Critical => Medium ** Changed in: keystone/juno Status: In Progress => Won't Fix ** Changed in: ossn 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/1434034 Title: Disabling users & groups may not invalidate previously-issued tokens Status in Keystone: Won't Fix Status in Keystone juno series: Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Confirmed Bug description: Even if the user is disabled, can use the last token is validated. 0. user foo is enable 1. get token (a) 2. user foo is disabled 3. foo can still use any APIs by token(a) that's all. This issue is not cache process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1434034/+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 1292591] Re: Database models differs from migrations.
I'm assuming this was fixed by the last patch. In the future, please use
Closes-Bug on the final patch in your patch sequence -- not just
Partial-Bug on all of them (which leaves the bug open).
** Changed in: keystone
Status: In Progress = Fix Committed
** Changed in: keystone
Milestone: None = 2015.1.0
** Changed in: keystone
Status: Fix Committed = 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/1292591
Title:
Database models differs from migrations.
Status in Keystone:
Fix Released
Bug description:
As models and migrations don't have any logical relation in code, so
differences are possible. Furthermore in most of cases differences
exists. The only way to solve this problem is using of specific test
such as this https://review.openstack.org/#/c/74081/ .
This is a diff example form Keystone:
AssertionError: Models and migration scripts aren't in sync:
[ [ ( 'modify_nullable',
None,
'federation_protocol',
'mapping_id',
{ 'existing_server_default': None,
'existing_type': VARCHAR(length=64)},
True,
False)],
[ ( 'modify_nullable',
None,
'region',
'description',
{ 'existing_server_default': None,
'existing_type': VARCHAR(length=255)},
False,
True)],
( 'remove_index',
Index(u'ix_revocation_event_revoked_at', Column(u'revoked_at',
DATETIME(), table=revocation_event, nullable=False))),
[ ( 'modify_nullable',
None,
'token',
'valid',
{ 'existing_server_default': None,
'existing_type': INTEGER()},
True,
False)]]
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1292591/+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 1488347] Re: Can't specify identity endpoint for token validation among several keystone servers in keystonemiddleware
A related conversation is occurring on the mailing list [1]. It sounds like this is a regression with the introduction of auth plugins to keystonemiddleware (Jamie, correct me if I'm wrong), so you might want to try using an older version of keystonemiddleware as a workaround. [1]: http://lists.openstack.org/pipermail/openstack- dev/2015-August/072521.html ** Project changed: keystone = keystonemiddleware ** Changed in: keystonemiddleware Importance: Undecided = Medium ** Changed in: keystonemiddleware Status: New = 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/1488347 Title: Can't specify identity endpoint for token validation among several keystone servers in keystonemiddleware Status in keystonemiddleware: Confirmed Bug description: Issue: Can't specify identity endpoint among several keystone servers in keystonemiddleware A prototype was executed to verify that KeyStone fernet token can work in multi-site OPNFV cloud(in OpenStack terms, multi-OpenStack regions): https://etherpad.opnfv.org/p/multisite_identity_management. the requirement is a user should, using a single authentication point be able to manage virtual resources spread over multiple OpenStack regions We have two regions: Kista and Solna, each one with KeyStone server installed, these two keystone servers will have MySql cluster as the backend, and the master MySql cluster in Kista, the slave MySql cluster in Solna which will be configured for aync-replication from the Kista MySql cluster, therefore the data in KeyStone database. root@51fa2177d59d:~# openstack endpoint list +--++--+--+-+---+--+ | ID | Region | Service Name | Service Type | Enabled | Interface | URL | +--++--+--+-+---+--+ | 09977a67a5fd4231bf54bfdbfc311b4e | Solna | keystone | identity | True| internal | http://172.17.0.98:5000 | | 18389f1ff42640cf905351a7f9b8a6f7 | Kista | glance | image| True| internal | http://172.17.0.41:9292 | | 3bd662e362e24f45a9db2b77ad0682bb | Solna | glance | image| True| internal | http://172.17.0.119:9292 | | 425b14d499264aa1bad8170a99afce88 | Kista | keystone | identity | True| admin | http://172.17.0.36:35357 | | 60a02a99078642d0974843323bbb8836 | Solna | glance | image| True| public| http://172.17.0.119:9292 | | 712d42d06ade4fedb8820e6f6ed33574 | Kista | glance | image| True| public| http://172.17.0.41:9292 | | 8000a62a8406437dad4759960bad837f | Kista | keystone | identity | True| public| http://172.17.0.36:5000 | | a7ec590712364e9f876f0b82d1879a99 | Kista | keystone | identity | True| internal | http://172.17.0.36:5000 | | b253565ee000417ab9b3d7ab3f4b4d48 | Solna | keystone | identity | True| admin | http://172.17.0.98:35357 | | bf9d05de9be64f5bb886959eb6bb367d | Solna | glance | image| True| admin | http://172.17.0.119:9292 | | d1cb2f7d7d594199909b14a0004f37fe | Kista | glance | image| True| admin | http://172.17.0.41:9292 | | eab9fbcb129741728bc72f36b72e27e2 | Solna | keystone | identity | True| public| http://172.17.0.98:5000 | +--++--+--+-+---+--+ Even the glance in Solna is configured with Solna KeyStone server for the fernet token validation locally, the token validation request was still routed to Kista KeyStone, it doesn't work as expected. The following dock describe the issue in detail: https://docs.google.com/document/d/1pvYWQprRH3jnzX2j- zQwAErdPWg9zwkguSyLx1EBKas/edit And this doc provides a patch to show how to make the configuration item being in effect for token validation locally: https://docs.google.com/document/d/1258g0VTC4wktevo2ymS7SaNhDeY8-S2QWY45them7ZM/edit# To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1488347/+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 1483382] Re: Able to request a V2 token for user and project in a non-default domain
Fixed by https://review.openstack.org/#/c/208069/
** Changed in: keystone
Importance: Undecided = High
** Changed in: keystone
Status: New = Fix Committed
** Changed in: keystone
Assignee: (unassigned) = Dolph Mathews (dolph)
** Also affects: keystone/kilo
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1483382
Title:
Able to request a V2 token for user and project in a non-default
domain
Status in Keystone:
Fix Committed
Status in Keystone kilo series:
New
Status in OpenStack Security Advisory:
Incomplete
Bug description:
Using the latest devstack, I am able to request a V2 token for user
and project in a non-default domain. This problematic as non-default
domains are not suppose to be visible to V2 APIs.
Steps to reproduce:
1) install devstack
2) run these commands
gyee@dev:~$ openstack --os-identity-api-version 3 --os-username admin
--os-password secrete --os-user-domain-id default --os-project-name admin
--os-project-domain-id default --os-auth-url http://localhost:5000 domain list
+--+-+-+--+
| ID | Name| Enabled | Description
|
+--+-+-+--+
| 769ad7730e0c4498b628aa8dc00e831f | foo | True|
|
| default | Default | True| Owns users and
tenants (i.e. projects) available on Identity API v2. |
+--+-+-+--+
gyee@dev:~$ openstack --os-identity-api-version 3 --os-username admin
--os-password secrete --os-user-domain-id default --os-project-name admin
--os-project-domain-id default --os-auth-url http://localhost:5000 user list
--domain 769ad7730e0c4498b628aa8dc00e831f
+--+--+
| ID | Name |
+--+--+
| cf0aa0b2d5db4d67a94d1df234c338e5 | bar |
+--+--+
gyee@dev:~$ openstack --os-identity-api-version 3 --os-username admin
--os-password secrete --os-user-domain-id default --os-project-name admin
--os-project-domain-id default --os-auth-url http://localhost:5000 project list
--domain 769ad7730e0c4498b628aa8dc00e831f
+--+-+
| ID | Name|
+--+-+
| 413abdbfef5544e2a5f3e8ac6124dd29 | foo-project |
+--+-+
gyee@dev:~$ curl -k -H 'Content-Type: application/json' -d '{auth:
{passwordCredentials: {userId: cf0aa0b2d5db4d67a94d1df234c338e5,
password: secrete}, tenantId: 413abdbfef5544e2a5f3e8ac6124dd29}}'
-XPOST http://localhost:35357/v2.0/tokens | python -mjson.tool
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 3006 100 2854 100 152 22164 1180 --:--:-- --:--:-- --:--:-- 22472
{
access: {
metadata: {
is_admin: 0,
roles: [
2b7f29ebd1c8453fb91e9cd7c2e1319b,
9fe2ff9ee4384b1894a90878d3e92bab
]
},
serviceCatalog: [
{
endpoints: [
{
adminURL:
http://10.0.2.15:8774/v2/413abdbfef5544e2a5f3e8ac6124dd29;,
id: 3a92a79a21fb41379fa3e135be65eeff,
internalURL:
http://10.0.2.15:8774/v2/413abdbfef5544e2a5f3e8ac6124dd29;,
publicURL:
http://10.0.2.15:8774/v2/413abdbfef5544e2a5f3e8ac6124dd29;,
region: RegionOne
}
],
endpoints_links: [],
name: nova,
type: compute
},
{
endpoints: [
{
adminURL:
http://10.0.2.15:8776/v2/413abdbfef5544e2a5f3e8ac6124dd29;,
id: 64338d9eb3054598bcee30443c678e2a,
internalURL:
http://10.0.2.15:8776/v2/413abdbfef5544e2a5f3e8ac6124dd29;,
publicURL:
http://10.0.2.15:8776/v2/413abdbfef5544e2a5f3e8ac6124dd29;,
region: RegionOne
}
],
endpoints_links
[Yahoo-eng-team] [Bug 1488208] [NEW] Revoking a role assignment revokes unscoped tokens too
Public bug reported: When you delete a role assignment using a user+role+project pairing, unscoped tokens between the user+project are unnecessarily revoked as well. In fact, two events are created for each role assignment deletion (one that is scoped correctly and one that is scoped too broadly). The test failure in https://review.openstack.org/#/c/216236/ illustrates this issue: http://logs.openstack.org/36/216236/1/check/gate-keystone- python27/3f44af1/ ** Affects: keystone Importance: Medium Assignee: Dolph Mathews (dolph) 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/1488208 Title: Revoking a role assignment revokes unscoped tokens too Status in Keystone: In Progress Bug description: When you delete a role assignment using a user+role+project pairing, unscoped tokens between the user+project are unnecessarily revoked as well. In fact, two events are created for each role assignment deletion (one that is scoped correctly and one that is scoped too broadly). The test failure in https://review.openstack.org/#/c/216236/ illustrates this issue: http://logs.openstack.org/36/216236/1/check/gate-keystone- python27/3f44af1/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1488208/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1487671] Re: ldap and ldappool packages are not mentioned in requirements.txt
See my comment on a related bug: https://bugs.launchpad.net/keystone/+bug/1487728/comments/2 ** 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/1487671 Title: ldap and ldappool packages are not mentioned in requirements.txt Status in Keystone: Invalid Bug description: The ldap backend driver depends on ldap and ldappool packages and wont work unless the packages are explicitly installed. How to reproduce 1) Create virtual env (mkvirtualenv keystone-ldap) 2) Check out git repo (git clone https://github.com/openstack/keystone -b stable/juno) 3) pip install -r requirements.txt 4)[GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import ldap Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named ldap To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1487671/+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 1487728] Re: ldap and ldappool modules are no listed in requirements file
LDAP dependencies are optional and are defined here: https://github.com/openstack/keystone/blob/master/setup.cfg#L25-L27 This takes advantage of setuptools extras: https://pythonhosted.org/setuptools/setuptools.html#declaring-extras- optional-features-with-their-own-dependencies Use the following pattern to install extra dependencies: $ pip install keystone[ldap] ** 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/1487728 Title: ldap and ldappool modules are no listed in requirements file Status in Keystone: Invalid Bug description: Configuring LDAP as assignment backend driver is causing some import modules errors. After reviewing the requirements.txt file, those dependencies are not listed there, but those dependencies are listed in requirements repo. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1487728/+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 1461299] Re: Failure on list users when using ldap domain configuration from database
** Tags removed: kilo-backport-potential ** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone Importance: Undecided = Medium ** Changed in: keystone/kilo 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/1461299 Title: Failure on list users when using ldap domain configuration from database Status in Keystone: Fix Committed Status in Keystone kilo series: New Status in oslo.config: Fix Released Bug description: When having a setup with domain_specific_drivers_enabled set to true, and a domain configured with ldap backend and configurations stored in the database : the keystone user list API fails with the following error: openstack user list --domain domainX ERROR: openstack An unexpected error prevented the server from fulfilling your request: Message objects do not support str() because they may contain non-ascii characters. Please use unicode() or translate() instead. (Disable debug mode to suppress these details.) (HTTP 500) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1461299/+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 1485712] Re: Can't set parent_id of project for hierarchical multi-tenancy
This is truly by design. But by disallowing it today, we've given ourselves the option to allow it in the future (we can't do the opposite: take an API feature away). The consequences of a mutable hierarchy are complicated and affect the rest of OpenStack (think quotas, for example), and the risk of unintended consequences, bugs, and security vulnerabilities is simply too great. It's far too early in hierarchical multitenancy's lifecycle to consider introducing all that extra complexity today. Perhaps once hierarchical multitenancy is a mature feature and we have a strong grasp of the consequences of a mutable hierarchy we could have that discussion again. ** Changed in: keystone Status: New = Won't Fix ** Changed in: keystone Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1485712 Title: Can't set parent_id of project for hierarchical multi-tenancy Status in Keystone: Won't Fix Bug description: I understand reading some of the specs for hierarchical multi-tenancy that you cannot change the parent_id of a project. But i would've hoped that if a project was created without a parent_id , you can later assign a parent, otherwise there's no clear migration path for projects that wish to utilize this feature and would have to destroy/recreate the project. When i tried it i get a 403, Update of `parent_id` is not allowed.. Is this just in place until it can be supported later, or is this truly by design? thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1485712/+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 1435693] Re: A number of places where we LOG messages fail to use the _L{X} formatting
I thought this was backportable since it's only adding translation
strings to stable/kilo (not modifying things that may have already been
translated).
** Changed in: keystone/kilo
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/1435693
Title:
A number of places where we LOG messages fail to use the _L{X}
formatting
Status in Keystone:
Fix Committed
Status in Keystone kilo series:
Invalid
Bug description:
These should be corrected.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1435693/+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 1484086] Re: ec2tokens authentication is failing during Heat tests
It wasn't a backwards incompatible change so much as resolving an apparent regression. v2 clients are not domain aware as there are no domain references in v2, so the potential for namespace collisions (bug 1475762) would be severe. ** Changed in: keystone Status: New = Incomplete ** Also affects: heat 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/1484086 Title: ec2tokens authentication is failing during Heat tests Status in heat: New Status in Keystone: Incomplete Bug description: As seen here for example: http://logs.openstack.org/54/194054/37/check /gate-heat-dsvm-functional-orig-mysql/a812f55/ We're getting the error: Non-default domain is not supported which seems to have been introduced here: https://review.openstack.org/#/c/208069/ To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1484086/+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 1484366] Re: No way to specify password strength in keystone.
The complexities of re-inventing a first class identity provider in
keystone are not in our best interests. Use a real identity provider
(via either LDAP or federation) that supports these features if you need
them, not the SQL backend.
** 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/1484366
Title:
No way to specify password strength in keystone.
Status in Keystone:
Won't Fix
Bug description:
There is a way to set the regular expression for horizon for a
password, but there is no way to do this in keystone.
We need a configuration parameter in keystone for the regular
expression and another one for the message to be shown when the
password is not valid.
#password regularexpression for user password
password_regex=((?=(.*(\d|[~!@#$%^*_=+])){2,})(?=.*[a-z])(?=.*[A-Z]).{8,20})
password_regex_message=Password is not strong enough
These then need to be validated in the respective controllers (both v2 and v3)
example in ./keystone/identity/controllers.py
209 @staticmethod
210 def check_syntax(password):
211 a = re.match(CONF.password_regex, password)
212 if not a:
213 raise exception.ValidationError(CONF.password_regex_message)
214
215 @staticmethod
216 def check_pwd_policies(password, name):
217
218 #if passsword is empty allow it,
219 #since empty password wont allow user to login
220 if password is None:
221 return
222 if name in password or password in name:
223 raise exception.ValidationError(Password not strong enough:
user name cannot be part of the password)
224 User.check_syntax(password)
225
243 @controller.protected()
244 def create_user(self, context, user):
245 self._require_attribute(user, 'name')
246
247 if user.get('password') is not None:
248 User.check_pwd_policies(user['password'], user['name'])
249 # The manager layer will generate the unique ID for users
250 ref = self._normalize_dict(user)
251 ref = self._normalize_domain_id(context, ref)
252 ref = self.identity_api.create_user(ref)
253 return UserV3.wrap_member(context, ref)
254
276 def _update_user(self, context, user_id, user):
277
278 #if password is being changed
279 #then check if name is not part of password
280 if 'password' in user:
281 #if name is not present then get it from the backend
282 if 'name' not in user:
283 old_user_ref = self.identity_api.get_user(user_id)
284 name = old_user_ref['name']
285 else:
286 name = user['name']
287 User.check_pwd_policies(user['password'], name)
288
289 self._require_matching_id(user_id, user)
290 self._require_matching_domain_id(
291 user_id, user, self.identity_api.get_user)
292 ref = self.identity_api.update_user(user_id, user)
293 return UserV3.wrap_member(context, ref)
315 @controller.protected()
316 def change_password(self, context, user_id, user):
317 original_password = user.get('original_password')
318 if original_password is None:
319 raise exception.ValidationError(target='user',
320 attribute='original_password')
321
322 password = user.get('password')
323 if password is None:
324 raise exception.ValidationError(target='user',
325 attribute='password')
326 #if name is not present then get it from the backend
327 if 'name' not in user:
328 old_user_ref = self.identity_api.get_user(user_id)
329 name = old_user_ref['name']
330 else:
331 name = user['name']
332
333 User.check_pwd_policies(password, name)
334
335 try:
336 self.identity_api.change_password(
337 context, user_id, original_password, password)
338 except AssertionError:
339 raise exception.Unauthorized()
340
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1484366/+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 1484451] Re: Project cannot be enabled after it was disabled
Cool, that's expected behavior then. ** 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/1484451 Title: Project cannot be enabled after it was disabled Status in Keystone: Invalid Bug description: After running the following command: # project set --disable project_name it is impossible to enable project with: # project set --enable project_name due to the following error: ERROR: openstack Project is disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1484451/+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 1435693] Re: A number of places where we LOG messages fail to use the _L{X} formatting
Closing because all the cited violations have been fixed.
Henry: when you have a bug fix that consists of multiple patches, use
Partial-Bug on all but the last patch in the sequence. On the last
patch, use Closes-Bug so that the bug will be automatically closed when
that patch merges.
** Changed in: keystone
Status: In Progress = Fix Committed
** Changed in: keystone
Milestone: None = liberty-3
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Changed in: keystone/kilo
Importance: Undecided = Low
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1435693
Title:
A number of places where we LOG messages fail to use the _L{X}
formatting
Status in Keystone:
Fix Committed
Status in Keystone kilo series:
New
Bug description:
These should be corrected.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1435693/+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 1471967] Re: Fernet unit tests do not test persistence logic
** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone/kilo Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1471967 Title: Fernet unit tests do not test persistence logic Status in Keystone: Fix Released Status in Keystone kilo series: New Bug description: There are some unit tests for the Fernet token provider that live outside of the functional-like tests (test_v3_auth.py, for example) [0]. These tests should include a test to assert that the Fernet token provider returns False when asked if it's tokens need persistence [1]. [0] https://github.com/openstack/keystone/blob/992d9ecbf4f563c42848147d4d66f8ec8efd4df0/keystone/tests/unit/token/test_fernet_provider.py [1] https://github.com/openstack/keystone/blob/992d9ecbf4f563c42848147d4d66f8ec8efd4df0/keystone/token/providers/fernet/core.py#L36-L38 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1471967/+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 1475762] Re: v3 Fernet tokens with references outside the default domain can be validated on v2
** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone/kilo 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/1475762 Title: v3 Fernet tokens with references outside the default domain can be validated on v2 Status in Keystone: Fix Committed Status in Keystone kilo series: New Bug description: v2 has no knowledge of multiple domains, so all ID references it sees must exist inside the default domain. So, a v3 token being validated on v2 must have a project-scope in the default domain, a user identity in the default domain, and obviously must not be a domain-scoped token. The current implementation of Fernet blindly returns tokens to the v2 API with (at least) project references that exist outside the default domain (I have not tested user references). The consequence is that v2 clients may end up with naming collisions (due to lack of domain namespacing). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1475762/+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 1482773] [NEW] H405 violations: multi line docstring summary not separated with an empty line
Public bug reported: Keystone's tox.ini contains an ignore entry for H405. All violations of H405 should be fixed so that H405 can be removed from the ignore list. ** Affects: keystone Importance: Low Assignee: Dolph Mathews (dolph) Status: In Progress ** Tags: low-hanging-fruit -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1482773 Title: H405 violations: multi line docstring summary not separated with an empty line Status in Keystone: In Progress Bug description: Keystone's tox.ini contains an ignore entry for H405. All violations of H405 should be fixed so that H405 can be removed from the ignore list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1482773/+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 1459790] Re: With fernet tokens, validate token loses the ms on 'expires' value
** Tags added: kilo-backport-potential
** Also affects: keystone/kilo
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1459790
Title:
With fernet tokens, validate token loses the ms on 'expires' value
Status in Keystone:
In Progress
Status in Keystone kilo series:
New
Bug description:
With fernet tokens, the expires ms value is 0 when the token is
validated. So the 'expires' on the post token and the get token are
different; this is not the case with uuid tokens.
$ curl -s \
-H Content-Type: application/json \
-d '{ auth:{ tenantName:testTenantName, passwordCredentials:{
username:testUserName, password:password }}}' \
-X POST $KEYSTONE_ENDPOINT:5000/v2.0/tokens | python -mjson.tool
post token portion of the response contains 'expires' with a ms value
:
token: {
audit_ids: [
eZtfF60tR7y5oAuL4LSr4w
],
expires: 2015-05-28T20:50:56.015102Z,
id:
gABVZ2OQu3OunvR6FKklDdNWj95Aq-ju_sIhB9o0KRin2SpLRUa0C3H_XiV_RWN409Ma-Q7lIkA_S6mY3bnxgboJZ_qxUiTdzUscG5y_fSCUW5sQqmB2AI1rlmMetvTl6AnnRKzVHVlJlDKQNHuk0MzHM3IVr4-ysJ2AHBtmDfkdpRZCrFo%3D,
issued_at: 2015-05-28T18:50:56.015211Z,
tenant: {
description: Test tenant ...,
enabled: true,
id: 1c6e0d2ac4bf4cd5bc7666d86b28aee0,
name: testTenantName,
parent_id: null
}
},
If this token is validated, the expires ms now show as 00Z
$ curl -s \
-H Content-Type: application/json \
-H X-Auth-Token: $ADMIN_TOKEN \
-X GET $KEYSTONE_ENDPOINT:35357/v2.0/tokens/$USER_TOKEN | python -mjson.tool
get token portion of the response contains 'expires' with ms = 00Z
],
token: {
audit_ids: [
lZwaM7oaShCZGQt0A9FaKA
],
expires: 2015-05-28T20:27:24.00Z,
id:
gABVZ14MKoaOBq4WBHaF1fqEKrN_nTrYYhwi8xrAisWmyJ52DJOrVlyxAoUuL_tfrGhslYVffRTosF5FqQVYlNq6hqU-qGzhueC4xVJZL8oitv0PfOdGfLgAWM1pciuiIdDLnWb-6oNrgZ9l1lHqn1kyuO0JVmS_YJfYI4YOt0o7ZfJhzFQ=,
issued_at: 2015-05-28T18:27:24.00Z,
tenant: {
description: Test tenant ...,
enabled: true,
id: 1c6e0d2ac4bf4cd5bc7666d86b28aee0,
name: testTenantName,
parent_id: null
}
},
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1459790/+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 1481152] Re: Pagination not working in Kilo
*** This bug is a duplicate of bug 1451402 *** https://bugs.launchpad.net/bugs/1451402 ** This bug has been marked a duplicate of bug 1451402 v3 - pagination in GET services does not work -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1481152 Title: Pagination not working in Kilo Status in Keystone: New Bug description: More than 100 users exists in the system. All users are listed when I execute below command GET url:35357/v3/users?page=2per_page=25 I noticed that bug 1451402 exists, but has been expired due to inactivity. Please let me know if pagination is supported in Identity V3. If so, do I need to configure anything before executing above command To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1481152/+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 1480787] Re: Pagination not working in Kilo
*** This bug is a duplicate of bug 1451402 *** https://bugs.launchpad.net/bugs/1451402 Pagination has not been implemented. To do so, it must be entirely controlled by the server (not the API client) due to the requirement to support multiple backends (SQL vs LDAP, for example). The page per_page scheme will not work for all drivers, and thus cannot be controlled by the end user, and is thus not a documented API. v3 does provide next and previous links for pagination purposes, but they are not currently populated. The closest behavior we have right now is server-defined limits on the number of resources returned by the backend in a single collection, which is controlled by keystone.conf list_limit. I've marked this bug as a dupe of 1451402 and re-opened that bug against openstack-api-site. It must have slipped my bug radar in the leadup to the summit; my apologies! ** This bug has been marked a duplicate of bug 1451402 v3 - pagination in GET services does not work -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1480787 Title: Pagination not working in Kilo Status in Keystone: New Bug description: I have created more than 100 users, but while I execute following command GET http://url:35357/v3/users?page=2\per_page=35 -v I am getting list of all users. I found this bug https://bugs.launchpad.net/bugs/1451402 has been expired due to inactivity. Can anyone confirm if pagination is supported in Identity API v3 or do I need to configure anything, so that pagination works? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1480787/+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 1451402] Re: v3 - pagination in GET services does not work
As mentioned in comment #2, the page and per_page parameters should be removed from http://developer.openstack.org/api-ref-identity-v3.html as they are not, and have never been, supported by keystone. ** Also affects: openstack-api-site 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/1451402 Title: v3 - pagination in GET services does not work Status in Keystone: Expired Status in openstack-api-site: New Bug description: When I execute GET http://xxx.xxx.xxx.xxx:35357/v3/services?page=2per_page=5 I expect to see a paginated collection returned (5 resources in total), however this is not the case. Instead I get back the full collection - so it seems like the query params are being ignored. The next and prev links don't reference the next page in the collection either. Do I need to configure the conf file or something? If so, I couldn't find it documented anywhere. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1451402/+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 1480270] Re: Can't get endpoints with v2 in command line
Although this is absolutely working as originally designed, it's effectively broken. This bug report may also be a dupe? Anyway, I think we (unfortunately) need to make a best guess to collapse multiple interface-specific, completely independent v3 endpoints into v2 endpoints (where at least a public URL is required, and admin internal endpoints cannot exist on their own, according to the v2 spec). ** Changed in: keystone Importance: Undecided = High ** Changed in: keystone Status: Invalid = Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1480270 Title: Can't get endpoints with v2 in command line Status in Keystone: Triaged Status in python-openstackclient: Invalid Bug description: Reproducible Steps: 1. Set up the latest devstack environment 2. Run the following commands $ source ~/devstack/accrc/admin/admin $ openstack endpoint list We can get nothing, but the endpoints data is real in db. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1480270/+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 1478656] Re: Non-numeric filenames in key_repository will make Keystone explode
** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone/kilo Status: New = In Progress ** Changed in: keystone/kilo Importance: Undecided = Low ** Changed in: keystone/kilo Assignee: (unassigned) = Dolph Mathews (dolph) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1478656 Title: Non-numeric filenames in key_repository will make Keystone explode Status in Keystone: Fix Committed Status in Keystone kilo series: In Progress Bug description: If one makes any files in that directory, such as an editor backup, Keystone will explode on startup or at the next key rotation because it assumes all files will pass int(filename) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1478656/+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 1479943] Re: XmlBodyMiddleware stubs break existing configs
stable/kilo https://review.openstack.org/#/c/205351/
** Changed in: keystone
Importance: Undecided = Medium
** Changed in: keystone
Status: New = Triaged
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Changed in: keystone/kilo
Status: New = Triaged
** Changed in: keystone/kilo
Importance: Undecided = Medium
** Changed in: keystone
Status: Triaged = Invalid
** Changed in: keystone/kilo
Assignee: (unassigned) = Tim Burke (1-tim-z)
** Changed in: keystone/kilo
Status: Triaged = In Progress
** Changed in: keystone/kilo
Assignee: Tim Burke (1-tim-z) = (unassigned)
** Changed in: keystone/kilo
Assignee: (unassigned) = Tim Burke (1-tim-z)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1479943
Title:
XmlBodyMiddleware stubs break existing configs
Status in Keystone:
Invalid
Status in Keystone kilo series:
In Progress
Bug description:
The Kilo Keystone release dropped support for requests with XML
bodies, but included shims to (presumably) prevent existing configs
from breaking. This works as desired for XmlBodyMiddleware, but not
XmlBodyMiddlewareV2 and XmlBodyMiddlewareV3. As a result, all client
requests to a pipeline with either of those filters will receive a 500
response and the server's logs look like
2015-07-30 19:06:57.029 22048 DEBUG keystone.middleware.core [-] RBAC:
auth_context: {} process_request
/vagrant/swift3/.tox/keystone/local/lib/python2.7/site-packages/keystone/middleware/core.py:239
2015-07-30 19:06:57.029 22048 ERROR keystone.common.wsgi [-]
'XmlBodyMiddlewareV2' object has no attribute 'application'
2015-07-30 19:06:57.029 22048 TRACE keystone.common.wsgi Traceback (most
recent call last):
2015-07-30 19:06:57.029 22048 TRACE keystone.common.wsgi File
/vagrant/swift3/.tox/keystone/local/lib/python2.7/site-packages/keystone/common/wsgi.py,
line 452, in __call__
2015-07-30 19:06:57.029 22048 TRACE keystone.common.wsgi response =
request.get_response(self.application)
2015-07-30 19:06:57.029 22048 TRACE keystone.common.wsgi AttributeError:
'XmlBodyMiddlewareV2' object has no attribute 'application'
2015-07-30 19:06:57.029 22048 TRACE keystone.common.wsgi
2015-07-30 19:06:57.055 22048 INFO eventlet.wsgi.server [-] 127.0.0.1 - -
[30/Jul/2015 19:06:57] GET /v2.0/tenants HTTP/1.1 500 423 0.027812
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1479943/+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 1420104] Re: quota set failed
** Changed in: keystone Status: Incomplete = 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/1420104 Title: quota set failed Status in Keystone: Invalid Status in OpenStack Compute (nova): Invalid Status in python-openstackclient: In Progress Bug description: 1: source file: export NOVA_VERSION=1.1 export no_proxy=$no_proxy, [overcloud_ip] export OS_PASSWORD=redhat export OS_TENANT_ID=86c0d2458dbb4adc990bab70ef3546f5 export OS_PROJECT_ID=86c0d2458dbb4adc990bab70ef3546f5 export OS_AUTH_URL=https://[overcloud_ip]:5000/v3 export OS_USER_DOMAIN_ID=9a03881b62ca449f87f8d5a1ceaad845 export OS_USERNAME=testuser_dx_px export COMPUTE_API_VERSION=1.1 export OS_NO_CACHE=True export OS_IDENTITY_API_VERSION=3 export OS_CACERT=/usr/local/share/ca-certificates/ephemeralca-cacert.crt PS2=$PS1 export PS1=($OS_USERNAME)$PS1 export OS_PS1=$PS2 2: testuser_dx_px was created via v3 keystone API as below: (admin)cetest@cer106n*:~/lily$ openstack domain create test_domain +-+--+ | Field | Value| +-+--+ | enabled | True | | id | 9a03881b62ca449f87f8d5a1ceaad845 | | name| test_domain | +-+--+ (admin)cetest@cer106n*:~/lily$ openstack project create --domain test_domain --description test project --enable te stproject_dx +-+--+ | Field | Value| +-+--+ | description | test project | | domain_id | 9a03881b62ca449f87f8d5a1ceaad845 | | enabled | True | | id | 86c0d2458dbb4adc990bab70ef3546f5 | | name| testproject_dx | +-+--+ (admin)cetest@cer106n*:~/lily$ openstack user create --password redhat --email testuser_dx...@hp.com --project testproject_dx --domai n test_domain --description user in test_domain and testproject_dx. --enable testuser_dx_px ++-+ | Field | Value | ++-+ | default_project_id | 86c0d2458dbb4adc990bab70ef3546f5| | description| user in test_domain and testproject_dx. | | domain_id | 9a03881b62ca449f87f8d5a1ceaad845| | email | testuser_dx...@hp.com | | enabled| True| | id | ddf3e092104b4f47bbf25dc39342159c| | name | testuser_dx_px | ++-+ 3: project quota set failed[openstackclient cmd] (testuser_dx_px)(testuser_dx_px)root@overcloud-ce-controller-controller1-gcf3ewgvxb4l:~# openstack --version openstack 0.4.1 (testuser_dx_px)(testuser_dx_px)root@overcloud-ce-controller-controller1-gcf3ewgvxb4l:~# openstack quota show testproject_dx +--++ | Field| Value | +--++ | backup_gigabytes | 1000 | | backups | 10 | | cores| -1 | | fixed-ips| -1 | | floating-ips | 10 | | gigabytes| 1000 | | injected-file-size | 10240 | | injected-files | 5 | | injected-path-size | 255| | instances| 40 | | key-pairs| 100| | project | testproject_dx | | properties | 50 | | ram | 16000 | | secgroup-rules | 20 | | secgroups| 10 | | server_group_members | 10 | | server_groups| 10 | | snapshots| 10 | | volumes | 10 | +--++ (testuser_dx_px)(testuser_dx_px)root@overcloud-ce-controller-controller1-gcf3ewgvxb4l:~# openstack quota set --ram 15360 testproject_dx ERROR: openstack Bad Request (HTTP 400) (Request-ID: req-29f562c4-8cf0-4e2f-97f0-d4a11bf16ebf) (testuser_dx_px)(testuser_dx_px)root@overcloud-ce-controller-controller1-gcf3ewgvxb4l:~# openstack quota show testproject_dx +--++ | Field| Value | +--++ | backup_gigabytes | 1000 | |
[Yahoo-eng-team] [Bug 1479981] Re: Openstackclient return wrong quota information
*** This bug is a duplicate of bug 1420104 *** https://bugs.launchpad.net/bugs/1420104 ** No longer affects: keystone ** This bug has been marked a duplicate of bug 1420104 quota set failed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1479981 Title: Openstackclient return wrong quota information Status in python-openstackclient: New Bug description: I try to update the quota port limitations for my project, neutronclient works well and I can get the right result using neutronclient. But when we run ```openstack quota show admin``` we found the quota port limitation doesn't changed. Here are the testing process: layton-pistachio:/opt/openstack # neutron --insecure --os-project-id d3a77adc69004a6bbfe233cf7f08fdc1 --os-project-domain-name default --os-user-domain-name default quota-update --port 160 +-+---+ | Field | Value | +-+---+ | floatingip | 50| | health_monitor | -1| | member | -1| | network | 10| | pool| 10| | port| 160 | | router | 10| | security_group | 10| | security_group_rule | 100 | | subnet | 10| | vip | 10| +-+---+ layton-pistachio:/opt/openstack # neutron --insecure --os-project-id d3a77adc69004a6bbfe233cf7f08fdc1 --os-project-domain-name default --os-user-domain-name default quota-show +-+---+ | Field | Value | +-+---+ | floatingip | 50| | health_monitor | -1| | member | -1| | network | 10| | pool| 10| | port| 160 | | router | 10| | security_group | 10| | security_group_rule | 100 | | subnet | 10| | vip | 10| +-+---+ layton-pistachio:/opt/openstack # openstack quota show admin +--+---+ | Field| Value | +--+---+ | backup_gigabytes | 1000 | | backups | 10| | cores| 20| | fixed-ips| -1| | floating-ips | 50| | gigabytes| 1000 | | health_monitor | -1| | injected-file-size | 10240 | | injected-files | 5 | | injected-path-size | 255 | | instances| 10| | key-pairs| 100 | | member | -1| | network | 10| | pool | 10| | port | 50| | project | admin | | properties | 128 | | ram | 51200 | | router | 10| | secgroup-rules | 100 | | secgroups| 10| | server_group_members | 10| | server_groups| 10| | snapshots| 10| | subnet | 10| | vip | 10| | volumes | 10| +--+---+ layton-pistachio:/opt/openstack # openstack project list +--+-+ | ID | Name| +--+-+ | 1c30e840b3d1447ea3820d99cc38cd33 | service | | 55d10960d5f7447990e69ebf481ac97d | demo| | d3a77adc69004a6bbfe233cf7f08fdc1 | admin | +--+-+ I checked the neutron database and the quota information was right: MariaDB [neutron] select * from quotas; +--+--+--+---+ | id | tenant_id| resource | limit | +--+--+--+---+ | 1c5586f5-7c71-4666-9162-bf29bcaa511d | d3a77adc69004a6bbfe233cf7f08fdc1 | port | 160 | +--+--+--+---+ 1 row in set (0.00 sec) To manage notifications about this bug go to: https://bugs.launchpad.net/python-openstackclient/+bug/1479981/+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 1465444] Re: Fernet key rotation removing keys early
** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone/kilo Status: New = In Progress ** Changed in: keystone/kilo Importance: Undecided = High ** Changed in: keystone/kilo Assignee: (unassigned) = Dolph Mathews (dolph) ** Tags removed: kilo-backport-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/1465444 Title: Fernet key rotation removing keys early Status in Keystone: Fix Released Status in Keystone kilo series: In Progress Bug description: When setting up Fernet key rotation with a maximum number of active of keys set to 25, it turned out that 'keystone-manage fernet_rotate' started deleting two keys once there reached 13 existing keys. It would waver between 12 and 13 keys every time it was rotated. It looks like this might be related to the range of keys to remove being negative : excess_keys = ( keys[:len(key_files) - CONF.fernet_tokens.max_active_keys + 1]) .. ends up being excess_keys = ( keys[:-11] ) .. which seems to be dipping back into the range of keys that should still be good and removing those. Adding something like: if len(key_files) - CONF.fernet_tokens.max_active_keys + 1 = 0 for the purge excess keys section seemed to allow us to generate all 25 keys, then rotate as normal. Once we hit the full 25 keys, this additional line was no longer needed. Attaching some log information showing the available keys going from 12, 13, 12, 13. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465444/+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 1479377] Re: Eror while installing keystone
** Project changed: keystone = keystone (Ubuntu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1479377 Title: Eror while installing keystone Status in keystone package in Ubuntu: New Bug description: While I am installing keystone and python client for it I am facing the following error: Traceback (most recent call last): File /usr/local/bin/keystone-manage, line 6, in module from keystone.cmd.manage import main ImportError: No module named cmd.manage dpkg: error processing package keystone (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: keystone The same is when I do sudo -s /bin/sh -c keystone-manage db_sync keystone To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1479377/+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 1478503] Re: test_admin_version_v3 actually tests public app
*** This bug is a duplicate of bug 1478504 *** https://bugs.launchpad.net/bugs/1478504 ** This bug has been marked a duplicate of bug 1478504 test_admin_version_v3 actually tests public app -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1478503 Title: test_admin_version_v3 actually tests public app Status in Keystone: Invalid Bug description: VersionTestCase.test_admin_version_v3 (keystone/tests/unit/test_versions.py) in fact tests public app: def test_admin_version_v3(self): client = tests.TestClient(self.public_app) It makes sense only in case of V3 eventless setup where public app handles bot endpoints, but I believe it should be tested by a separate test like .test_admin_version_v3_eventlets which will be introduced as part of fix of bug #1381961. Also this behavior was introduced when 2 apps setup was used for eventless. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1478503/+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 1478466] Re: Apache2 fail to start
Was something else already running on port 5000, perhaps? ** Project changed: keystone = packstack -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1478466 Title: Apache2 fail to start Status in Packstack: New Bug description: Using OpenStack Juno rdo-release-juno-1.noarch.rpm. Installation Method: packstack on fedora 20 x64 Error: Execution of '/sbin/service httpd start' returned 1 When check on httpd/apache2 status it shows following error (13)Permission denied: AH00072: make_sock: could not bind to address ...:5000 Solution: Open /etc/httpd/conf and comment out port 5000 and 35357 . Close the file and restart the service. It will start running. To manage notifications about this bug go to: https://bugs.launchpad.net/packstack/+bug/1478466/+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 1477373] Re: No way to convert V2 tokens to V3 if domain id changes
This is proposing an API impacting solution to a deprecated API, and completely glossing over the problem being addressed. If they default domain changes, the tokens will not be properly converted. What does this mean? ** 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/1477373 Title: No way to convert V2 tokens to V3 if domain id changes Status in Keystone: Invalid Bug description: While many people are still stuck on V2 tokens, we need a safe way to map them to V3. If they default domain changes, the tokens will not be properly converted. THe best that can be done now is to guess that the domain_id is default and the name is Default both these values should be included as hints in V2 tokens until they are completely removed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1477373/+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 1476329] [NEW] v2 tokens validated on the v3 API are missing timezones
Public bug reported: v3 tokens contain the issued_at and expires_at timestamps for each token. If a token is created on the v2 API and then validated on the v3 API, this timezone information is missing (the 'Z' at the end of the timestamp), and thus cannot be validated as ISO 8601 extended format timestamps. This patch contains two FIXMEs which, if uncommented, will reproduce this bug: https://review.openstack.org/#/c/203250/ This appears to affect all token formats. ** Affects: keystone Importance: Medium Status: Triaged ** Description changed: v3 tokens contain the issued_at and expires_at timestamps for each token. If a token is created on the v2 API and then validated on the v3 API, this timezone information is missing (the 'Z' at the end of the timestamp), and thus cannot be validated as ISO 8601 extended format timestamps. + + This patch contains two FIXMEs which, if uncommented, will reproduce + this bug: + + https://review.openstack.org/#/c/203250/ ** Description changed: v3 tokens contain the issued_at and expires_at timestamps for each token. If a token is created on the v2 API and then validated on the v3 API, this timezone information is missing (the 'Z' at the end of the timestamp), and thus cannot be validated as ISO 8601 extended format timestamps. This patch contains two FIXMEs which, if uncommented, will reproduce this bug: - https://review.openstack.org/#/c/203250/ + https://review.openstack.org/#/c/203250/ + + This appears to affect all token formats. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1476329 Title: v2 tokens validated on the v3 API are missing timezones Status in Keystone: Triaged Bug description: v3 tokens contain the issued_at and expires_at timestamps for each token. If a token is created on the v2 API and then validated on the v3 API, this timezone information is missing (the 'Z' at the end of the timestamp), and thus cannot be validated as ISO 8601 extended format timestamps. This patch contains two FIXMEs which, if uncommented, will reproduce this bug: https://review.openstack.org/#/c/203250/ This appears to affect all token formats. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1476329/+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 1475796] Re: using pysaml2 version 3.0.0 breaks keystone in kilo release 2015.1.0
** Also affects: keystone/kilo Importance: Undecided Status: New ** Tags removed: kilo-backport-potential ** Changed in: keystone/kilo Status: New = Triaged ** Changed in: keystone/kilo Importance: Undecided = High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1475796 Title: using pysaml2 version 3.0.0 breaks keystone in kilo release 2015.1.0 Status in Keystone: New Status in Keystone kilo series: Triaged Bug description: pysaml2 version 3.0.0 it's a major change as specified in [1]: 2)All parts of the package is now collected in one module. This is a change that breaking change compared to earlier releases hence the major version change.. when running keystone release 2015.1.0 with python package pysaml2 version 3.0.0 breaks it with the following error: File /usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 22, in import_string return pkg_resources.EntryPoint.parse(x= + s).load(False) File /usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 2355, in load return self.resolve() File /usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 2361, in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0) File /usr/lib/python2.7/site-packages/keystone/contrib/federation/routers.py, line 17, in module from keystone.contrib.federation import controllers File /usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py, line 29, in module from keystone.contrib.federation import idp as keystone_idp File /usr/lib/python2.7/site-packages/keystone/contrib/federation/idp.py, line 29, in module import xmldsig ImportError: No module named xmldsig This is due to the new location for xmldsig module: xmldsig - saml2/xmldsig done in commit [2]. Possible fixes are: 1) require pysaml2 version 3.0.0 2) cherry-pick patch from kesytone master branch with the proper fix [3] [1] - https://github.com/rohe/pysaml2/releases/tag/3.0.0 [2] - https://github.com/rohe/pysaml2/commit/9af3252035484f4a8c624eba0f35b68280d43fd2 [3] - https://github.com/openstack/keystone/commit/c90dd3a0f8280e28bbbff691c0ae27aff736658a To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1475796/+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 1454309] Re: Keystone v3 user/tenant lookup by name via OpenStack CLI client fails
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Changed in: keystone/kilo
Importance: Undecided = High
** Changed in: keystone/kilo
Assignee: (unassigned) = Dolph Mathews (dolph)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1454309
Title:
Keystone v3 user/tenant lookup by name via OpenStack CLI client fails
Status in Keystone:
Fix Released
Status in Keystone kilo series:
In Progress
Bug description:
When using the openstack CLI client to look up users/tenants by name
(e.g., openstack user show admin or openstack openstack project show
AdminTenant), it fails with a 500 and the following traceback:
2015-05-12 09:27:22.483530 2015-05-12 09:27:22.483 31012 DEBUG
keystone.common.ldap.core [-] LDAP search: base=ou=People,dc=local,dc=lan
scope=2 filterstr=((None(sn=admin))(objectClass=inetOrgPerson)) attrs=['cn',
'userPassword', 'enabled', 'sn', 'mail'] attrsonly=0 search_s
/usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py:931
2015-05-12 09:27:22.483677 2015-05-12 09:27:22.483 31012 DEBUG
keystone.common.ldap.core [-] LDAP unbind unbind_s
/usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py:904
2015-05-12 09:27:22.485831 2015-05-12 09:27:22.483 31012 ERROR
keystone.common.wsgi [-] {'desc': 'Bad search filter'}
2015-05-12 09:27:22.485874 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi Traceback (most recent call last):
2015-05-12 09:27:22.485881 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py, line 239, in
__call__
2015-05-12 09:27:22.485885 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi result = method(context, **params)
2015-05-12 09:27:22.485897 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/common/controller.py, line 202, in
wrapper
2015-05-12 09:27:22.485901 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi return f(self, context, filters, **kwargs)
2015-05-12 09:27:22.485904 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/identity/controllers.py, line 223,
in list_users
2015-05-12 09:27:22.485908 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi hints=hints)
2015-05-12 09:27:22.485911 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/common/manager.py, line 52, in
wrapper
2015-05-12 09:27:22.485915 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi return f(self, *args, **kwargs)
2015-05-12 09:27:22.485919 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/identity/core.py, line 342, in
wrapper
2015-05-12 09:27:22.485922 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi return f(self, *args, **kwargs)
2015-05-12 09:27:22.485926 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/identity/core.py, line 353, in
wrapper
2015-05-12 09:27:22.485930 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi return f(self, *args, **kwargs)
2015-05-12 09:27:22.485933 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/identity/core.py, line 791, in
list_users
2015-05-12 09:27:22.485937 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi ref_list = driver.list_users(hints)
2015-05-12 09:27:22.485941 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/identity/backends/ldap.py, line 82,
in list_users
2015-05-12 09:27:22.485944 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi return self.user.get_all_filtered(hints)
2015-05-12 09:27:22.485948 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/identity/backends/ldap.py, line
269, in get_all_filtered
2015-05-12 09:27:22.485951 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi return [self.filter_attributes(user) for user in
self.get_all(query)]
2015-05-12 09:27:22.485964 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py, line 1863, in
get_all
2015-05-12 09:27:22.485968 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi for x in self._ldap_get_all(ldap_filter)
2015-05-12 09:27:22.485972 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi File
/usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py, line 1467, in
_ldap_get_all
2015-05-12 09:27:22.485975 2015-05-12 09:27:22.483 31012 TRACE
keystone.common.wsgi attrs)
2015-05-12 09:27:22.485979 2015-05-12 09:27:22.483 31012
[Yahoo-eng-team] [Bug 1474491] [NEW] keystone.tests.unit.test_config fails in isolation
Public bug reported:
While investigating bug 1474069, I discovered this test fails when run
in isolation as well.
$ tox -e py27 keystone.tests.unit.test_config
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --list
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --load-list /tmp/tmpXPUxi4
==
FAIL: keystone.tests.unit.test_config.DeprecatedOverrideTestCase.test_sql
tags: worker-0
--
Empty attachments:
pythonlogging:''-1
stderr
stdout
pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.unit.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File keystone/tests/unit/test_config.py, line 81, in test_sql
self.assertEqual('sqlite://new', CONF.database.connection)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 1902, in __getattr__
raise NoSuchOptError(name)
oslo_config.cfg.NoSuchOptError: no such option: database
==
FAIL: keystone.tests.unit.test_config.DeprecatedTestCase.test_sql
tags: worker-0
--
Empty attachments:
pythonlogging:''-1
stderr
stdout
pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.unit.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File keystone/tests/unit/test_config.py, line 65, in test_sql
self.assertEqual('sqlite://deprecated', CONF.database.connection)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 1902, in __getattr__
raise NoSuchOptError(name)
oslo_config.cfg.NoSuchOptError: no such option: database
Ran 4 (+3) tests in 0.032s (-0.357s)
FAILED (id=5988, failures=2 (+2))
The individual tests fail when run in isolation as well. For example:
$ tox -e py27
keystone.tests.unit.test_config.DeprecatedOverrideTestCase.test_sql
$ tox -e py27 keystone.tests.unit.test_config.DeprecatedTestCase.test_sql
** Affects: keystone
Importance: Low
Status: Triaged
** Tags: low-hanging-fruit test-improvement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1474491
Title:
keystone.tests.unit.test_config fails in isolation
Status in Keystone:
Triaged
Bug description:
While investigating bug 1474069, I discovered this test fails when run
in isolation as well.
$ tox -e py27 keystone.tests.unit.test_config
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --list
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --load-list /tmp/tmpXPUxi4
==
FAIL: keystone.tests.unit.test_config.DeprecatedOverrideTestCase.test_sql
tags: worker-0
--
Empty attachments:
pythonlogging:''-1
stderr
stdout
pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.unit.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File keystone/tests/unit/test_config.py, line 81, in test_sql
self.assertEqual('sqlite://new', CONF.database.connection)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 1902, in __getattr__
raise NoSuchOptError(name)
oslo_config.cfg.NoSuchOptError: no such option: database
==
FAIL: keystone.tests.unit.test_config.DeprecatedTestCase.test_sql
tags: worker-0
--
Empty attachments:
pythonlogging:''-1
stderr
stdout
pythonlogging:'': {{{Adding cache-proxy
'keystone.tests.unit.test_cache.CacheIsolatingProxy' to backend.}}}
Traceback (most recent call last):
File keystone/tests/unit/test_config.py, line 65, in test_sql
self.assertEqual('sqlite://deprecated', CONF.database.connection)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 1902, in __getattr__
raise
[Yahoo-eng-team] [Bug 1474162] Re: ldap unicode issue when doing a show user
Ah, then we need to backport the fix for bug 1448286 (which is already tagged for backporting), along with the fix for bug 1454968 (which my fix for the first bug triggered). Closing this bug as we need to track against the bugs merged to master. ** 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/1474162 Title: ldap unicode issue when doing a show user Status in Keystone: Invalid Bug description: In stable/kilo release, when the username contains non ascii charaters, showing the user from ldap with the following command - openstack user show --domain=ad Test Accent Communiquè will throw an exception. And this has been addressed in the Master branch, so what needs to be done is just to backport the changes to stable/kilo. I tested the changes in the Master branch and works fine. This is similar to https://bugs.launchpad.net/keystone/+bug/1419187 (keystone.common.wsgi): 2015-07-10 21:25:26,351 INFO wsgi __call__ GET /domains?name=ad (keystone.common.wsgi): 2015-07-10 21:25:26,385 ERROR wsgi __call__ 'ascii' codec can't encode character u'\xe8' in position 21: ordinal not in range(128) Traceback (most recent call last): File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/keystone/common/wsgi.py, line 452, in __call__ response = request.get_response(self.application) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/request.py, line 1317, in send application, catch_exc_info=False) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/request.py, line 1281, in call_application app_iter = application(self.environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File
[Yahoo-eng-team] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Also affects: keystone/juno
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/1465922
Title:
Password visible in clear text in keystone.log when user created and
keystone debug logging is enabled
Status in Keystone:
Fix Committed
Status in Keystone juno series:
New
Status in Keystone kilo series:
New
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
grep CLEARTEXTPASSWORD keystone.log
2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-]
RBAC: Authorizing identity:create_user(user={u'domain_id': u'default',
u'password': u'CLEARTEXTPASSWORD', u'enabled': True,
u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name':
u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site-
packages/keystone/common/controller.py:57
Issue code:
https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57
LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {
'action': action,
'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])})
Shadow the values of sensitive fields like 'password' by some
meaningless garbled text like X is one way to fix.
Well, in addition to this, I think we should never pass the 'password'
with its original value along the code and save it in any persistence,
instead we should convert it to a strong hash value as early as
possible. With the help of a good hash system, we never have to need
the original value of the password, right?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1454968] Re: hard to understand the uri printed in the log
** Also affects: keystone/juno
Importance: Undecided
Status: New
** Changed in: keystone/juno
Status: New = In Progress
** Changed in: keystone/juno
Importance: Undecided = Medium
** Changed in: keystone/juno
Assignee: (unassigned) = Dolph Mathews (dolph)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1454968
Title:
hard to understand the uri printed in the log
Status in Keystone:
Fix Released
Status in Keystone juno series:
In Progress
Status in Keystone kilo series:
In Progress
Bug description:
In keystone's log file, we can easily find some uri printed like this:
http://127.0.0.1:35357/v3/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens
seems there is something wrong when we are trying to log the uri in the log
file.
LOG.info('%(req_method)s %(uri)s', {
'req_method': req.environ['REQUEST_METHOD'].upper(),
'uri': wsgiref.util.request_uri(req.environ),
})
code is here:
https://github.com/openstack/keystone/blob/0debc2fbf448b44574da6f3fef7d457037c59072/keystone/common/wsgi.py#L232
but seems it has already been wrong when the req is passed in.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1454968/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1454968] Re: hard to understand the uri printed in the log
** Also affects: keystone/kilo
Importance: Undecided
Status: New
** Changed in: keystone/kilo
Assignee: (unassigned) = Dolph Mathews (dolph)
** Changed in: keystone/kilo
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/1454968
Title:
hard to understand the uri printed in the log
Status in Keystone:
Fix Released
Status in Keystone kilo series:
In Progress
Bug description:
In keystone's log file, we can easily find some uri printed like this:
http://127.0.0.1:35357/v3/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens/auth/tokens
seems there is something wrong when we are trying to log the uri in the log
file.
LOG.info('%(req_method)s %(uri)s', {
'req_method': req.environ['REQUEST_METHOD'].upper(),
'uri': wsgiref.util.request_uri(req.environ),
})
code is here:
https://github.com/openstack/keystone/blob/0debc2fbf448b44574da6f3fef7d457037c59072/keystone/common/wsgi.py#L232
but seems it has already been wrong when the req is passed in.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1454968/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1448286] Re: unicode query string raises UnicodeEncodeError
In order for this to be safely backported to kilo, the fix for bug 1454968 needs to be included as well (the fix for this bug revealed the problem fixed in bug 1454968). ** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone/kilo Assignee: (unassigned) = Dolph Mathews (dolph) ** Changed in: keystone/kilo 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/1448286 Title: unicode query string raises UnicodeEncodeError Status in Keystone: Fix Released Status in Keystone kilo series: In Progress Bug description: The logging in keystone.common.wsgi is unable to handle unicode query strings. The simplest example would be: $ curl http://localhost:35357/?Ϡ This will fail with a backtrace similar to: 2015-04-24 19:57:45.860 22255 TRACE keystone.common.wsgi File .../keystone/keystone/common/wsgi.py, line 234, in __call__ 2015-04-24 19:57:45.860 22255 TRACE keystone.common.wsgi 'params': urllib.urlencode(req.params)}) 2015-04-24 19:57:45.860 22255 TRACE keystone.common.wsgi File /usr/lib/python2.7/urllib.py, line 1311, in urlencode 2015-04-24 19:57:45.860 22255 TRACE keystone.common.wsgi k = quote_plus(str(k)) 2015-04-24 19:57:45.860 22255 TRACE keystone.common.wsgi UnicodeEncodeError: 'ascii' codec can't encode character u'\u03e0' in position 0: ordinal not in range(128) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1448286/+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 1474162] Re: ldap unicode issue when doing a show user
*** This bug is a duplicate of bug 1448286 *** https://bugs.launchpad.net/bugs/1448286 For reference, here's a direct link to the stable/kilo backport of both issues: https://review.openstack.org/#/c/201708/ ** This bug has been marked a duplicate of bug 1448286 unicode query string raises UnicodeEncodeError -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1474162 Title: ldap unicode issue when doing a show user Status in Keystone: Invalid Bug description: In stable/kilo release, when the username contains non ascii charaters, showing the user from ldap with the following command - openstack user show --domain=ad Test Accent Communiquè will throw an exception. And this has been addressed in the Master branch, so what needs to be done is just to backport the changes to stable/kilo. I tested the changes in the Master branch and works fine. This is similar to https://bugs.launchpad.net/keystone/+bug/1419187 (keystone.common.wsgi): 2015-07-10 21:25:26,351 INFO wsgi __call__ GET /domains?name=ad (keystone.common.wsgi): 2015-07-10 21:25:26,385 ERROR wsgi __call__ 'ascii' codec can't encode character u'\xe8' in position 21: ordinal not in range(128) Traceback (most recent call last): File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/keystone/common/wsgi.py, line 452, in __call__ response = request.get_response(self.application) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/request.py, line 1317, in send application, catch_exc_info=False) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/request.py, line 1281, in call_application app_iter = application(self.environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__ return resp(environ, start_response) File /opt/stack/service/keystone/venv/lib/python2.7/site-packages/routes/middleware.py, line 136, in __call__ response = self.app(environ, start_response) File
[Yahoo-eng-team] [Bug 1474490] [NEW] keystone.tests.unit.common.test_notifications.NotificationsTestCase fails in isolation
Public bug reported:
While investigating bug 1474069, I discovered this test fails when run
in isolation as well.
$ tox -e py27
keystone.tests.unit.common.test_notifications.NotificationsTestCase
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --list
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --load-list /tmp/tmpARu0Eo
==
FAIL:
keystone.tests.unit.common.test_notifications.NotificationsTestCase.test_send_notification
tags: worker-0
--
Empty attachments:
pythonlogging:''
stderr
stdout
Traceback (most recent call last):
File keystone/tests/unit/common/test_notifications.py, line 182, in setUp
fixture.config(rpc_backend='fake', notification_driver=['fake'])
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/fixture.py,
line 65, in config
self.conf.set_override(k, v, group)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 1824, in __inner
result = f(self, *args, **kwargs)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 2103, in set_override
opt_info = self._get_opt_info(name, group)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 2421, in _get_opt_info
raise NoSuchOptError(opt_name, group)
oslo_config.cfg.NoSuchOptError: no such option: notification_driver
Ran 1 tests in 0.005s (-0.431s)
FAILED (id=7051, failures=1 (+1))
** Affects: keystone
Importance: Low
Status: Triaged
** Tags: low-hanging-fruit test-improvement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1474490
Title:
keystone.tests.unit.common.test_notifications.NotificationsTestCase
fails in isolation
Status in Keystone:
Triaged
Bug description:
While investigating bug 1474069, I discovered this test fails when run
in isolation as well.
$ tox -e py27
keystone.tests.unit.common.test_notifications.NotificationsTestCase
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --list
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./keystone/tests/unit} --load-list /tmp/tmpARu0Eo
==
FAIL:
keystone.tests.unit.common.test_notifications.NotificationsTestCase.test_send_notification
tags: worker-0
--
Empty attachments:
pythonlogging:''
stderr
stdout
Traceback (most recent call last):
File keystone/tests/unit/common/test_notifications.py, line 182, in setUp
fixture.config(rpc_backend='fake', notification_driver=['fake'])
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/fixture.py,
line 65, in config
self.conf.set_override(k, v, group)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 1824, in __inner
result = f(self, *args, **kwargs)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 2103, in set_override
opt_info = self._get_opt_info(name, group)
File
/home/dolph/venv/os/local/lib/python2.7/site-packages/oslo_config/cfg.py,
line 2421, in _get_opt_info
raise NoSuchOptError(opt_name, group)
oslo_config.cfg.NoSuchOptError: no such option: notification_driver
Ran 1 tests in 0.005s (-0.431s)
FAILED (id=7051, failures=1 (+1))
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1474490/+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 1473298] Re: Cannot create keystone trust with python-openstackclient using trustor/trustee id
** Project changed: keystone = python-openstackclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1473298 Title: Cannot create keystone trust with python-openstackclient using trustor/trustee id Status in python-openstackclient: New Bug description: Creating Keystone V3 trusts (Kilo 2015.1.0) with python- openstackclient (OSC) 1.5.0 works fine when using trustor user and trustee user names but doesn't when using IDs. Keystone log (verbose) doesn't return any error/warning, so that might be an OSC issue. # openstack user show adminv3 --format shell domain_id=43c0586acd1b48b5ad544600414700fb email=t...@example.tld enabled=True id=24b047f52ff94029923f7f0ea982f03f name=adminv3 # openstack trust create --format shell --role admin --project openstackv3 adminv3 foo deleted_at=None expires_at=None id=c42c31ac89a0465da6f23121a64570c1 impersonation=False project_id=78e22bb71862481dbe8335b4ce4551e8 redelegation_count=0 remaining_uses=None roles=admin trustee_user_id=ac994e5701d644b6a3ac78c9dd1ad04a trustor_user_id=24b047f52ff94029923f7f0ea982f03f # openstack trust create --format shell --role admin --project openstackv3 24b047f52ff94029923f7f0ea982f03f foo ERROR: openstack No user with a name or ID of '24b047f52ff94029923f7f0ea982f03f' exists. To manage notifications about this bug go to: https://bugs.launchpad.net/python-openstackclient/+bug/1473298/+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 1472503] Re: python-ldap 2.4.20 causing install issues
** 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/1472503 Title: python-ldap 2.4.20 causing install issues Status in OpenStack Identity (Keystone): Invalid Status in pbr package in Ubuntu: Confirmed Bug description: I use the lastest devstack and lastest keystone, and the install error from devstack is like this: 2015-07-08 07:15:36.238 | + local name=keystone 2015-07-08 07:15:36.238 | + /opt/stack/requirements/.venv/bin/edit-constraints /opt/stack/requirements/upper-constraints.txt -- keystone '-e file:///opt/stack/keystone#egg=keystone' 2015-07-08 07:15:36.315 | + setup_package /opt/stack/keystone -e 2015-07-08 07:15:36.315 | + local project_dir=/opt/stack/keystone 2015-07-08 07:15:36.315 | + local flags=-e 2015-07-08 07:15:36.315 | + pip_install -e /opt/stack/keystone 2015-07-08 07:15:36.592 | + sudo -H http_proxy=http://proxy01.cd.intel.com:911 https_proxy=http://proxy01.cd.intel.com:911 'no_proxy=intel.com,*.intel.com,10.0.0.0/8,192.168.0.0/16,127.0.0.0/8,localhost,127.0.0.1,192.168.140.145' PIP_FIND_LINKS=file:///opt/stack/.wheelhouse /usr/local/bin/pip install -e /opt/stack/keystone 2015-07-08 07:15:37.358 | Obtaining file:///opt/stack/keystone 2015-07-08 07:15:38.004 | Complete output from command python setup.py egg_info: 2015-07-08 07:15:38.004 | error in setup command: 'tests_require' must be a string or list of strings containing valid project/version requirement specifiers; Expected ',' or end-of-list in python-ldap=2.4;python_version=='2.7' at ;python_version=='2.7' 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | Command python setup.py egg_info failed with error code 1 in /opt/stack/keystone 2015-07-08 07:15:38.015 | + exit_trap 2015-07-08 07:15:38.015 | + local r=1 2015-07-08 07:15:38.016 | ++ jobs -p 2015-07-08 07:15:38.016 | + jobs= 2015-07-08 07:15:38.016 | + [[ -n '' ]] 2015-07-08 07:15:38.016 | + kill_spinner 2015-07-08 07:15:38.016 | + '[' '!' -z '' ']' 2015-07-08 07:15:38.016 | + [[ 1 -ne 0 ]] 2015-07-08 07:15:38.016 | + echo 'Error on exit' 2015-07-08 07:15:38.017 | Error on exit 2015-07-08 07:15:38.017 | + [[ -z /opt/stack/logs ]] 2015-07-08 07:15:38.017 | + /home/stack/devstack/devstack/tools/worlddump.py -d /opt/stack/logs 2015-07-08 07:15:38.051 | df: '/run/user/112/gvfs': Permission denied 2015-07-08 07:15:38.484 | + exit 1 stack@stack-PC44-8000:~/devstack/devstack$ 2015-07-08 07:15:38.490 | /bin/sh: 1: kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or 2015-07-08 07:15:38.490 | kill -l [exitstatus] seems this line in https://review.openstack.org/#/c/197773/2/test-requirements.txt python-ldap=2.4;python_version=='2.7' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1472503/+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 1472060] Re: websso callback is in the wrong place
** Tags added: federation
** Changed in: keystone
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1472060
Title:
websso callback is in the wrong place
Status in OpenStack Identity (Keystone):
Opinion
Bug description:
We have all this infrastructure in /OS-
FEDERATION/identity_providers/{id}/protocol/{id} to uniquely identify
the relationship between an identity provider and a protocol for
interacting with that provider so we can apply mappings. With websso
we then hard code a route of /OS-FEDERATION/websso/{protocol}. Because
we have just stripped the identity_provider from the URL we then have
to add remote_ids to the identity_providers so that the
websso/protocol route can figure out which idp we are talking about
and lookup the idp.
We have a route that includes the idp id and protocol and if we had
put the websso route at /OS-
FEDERATION/identity_providers/{id}/protocol/{id}/websso (next to where
/auth) lives we wouldn't need the multiple locations in the httpd
config and we wouldn't need to add remote_ids to the idp (because
we've already established this once in httpd).
I'm sure there are advantages to this too but what was the point of
/identity_providers/{id}/protocol/{id} if we're going to have to
establish remote_id relationships back to and IDP?
/rant
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1472060/+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 1471943] Re: KeystoneClient OS-FEDERATION needs to handle EmptyCatalog
** Tags added: federation ** Project changed: keystone = python-keystoneclient ** Changed in: python-keystoneclient 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/1471943 Title: KeystoneClient OS-FEDERATION needs to handle EmptyCatalog Status in Python client library for Keystone: In Progress Bug description: When listing federated projects using unscoped token an EmptyCatalog Exception is thrown. KeystoneClient should handle this exception. Line 36 in [1] [1] https://github.com/openstack/python-keystoneclient/blob/feature/keystoneauth_integration/keystoneclient/v3/contrib/federation/base.py To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1471943/+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 1470898] Re: keystoneclient client doesn't install cleanly with pip
apt-get install python-dev
** 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/1470898
Title:
keystoneclient client doesn't install cleanly with pip
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
I've tried this on ubuntu 12.04, 14.04 and 15.04. All reported the
same problem as follows:
sudo apt-get update
sudo apt-get install -y python-pip
sudo pip install python-keystoneclient
the installation makes it almost to the end and reports this:
building 'netifaces' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-
prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-
protector-strong -Wformat -Werror=format-security -fPIC
-DNETIFACES_VERSION=0.10.4 -DHAVE_GETIFADDRS=1 -DHAVE_GETNAMEINFO=1
-DHAVE_NETASH_ASH_H=1 -DHAVE_NETATALK_AT_H=1 -DHAVE_NETAX25_AX25_H=1
-DHAVE_NETECONET_EC_H=1 -DHAVE_NETIPX_IPX_H=1
-DHAVE_NETPACKET_PACKET_H=1 -DHAVE_LINUX_IRDA_H=1 -DHAVE_LINUX_ATM_H=1
-DHAVE_LINUX_LLC_H=1 -DHAVE_LINUX_TIPC_H=1 -DHAVE_LINUX_DN_H=1
-DHAVE_SOCKADDR_AT=1 -DHAVE_SOCKADDR_AX25=1 -DHAVE_SOCKADDR_IN=1
-DHAVE_SOCKADDR_IN6=1 -DHAVE_SOCKADDR_IPX=1 -DHAVE_SOCKADDR_UN=1
-DHAVE_SOCKADDR_ASH=1 -DHAVE_SOCKADDR_EC=1 -DHAVE_SOCKADDR_LL=1
-DHAVE_SOCKADDR_ATMPVC=1 -DHAVE_SOCKADDR_ATMSVC=1 -DHAVE_SOCKADDR_DN=1
-DHAVE_SOCKADDR_IRDA=1 -DHAVE_SOCKADDR_LLC=1 -DHAVE_PF_NETLINK=1
-I/usr/include/python2.7 -c netifaces.c -o build/temp.linux-
x86_64-2.7/netifaces.o
netifaces.c:1:20: fatal error: Python.h: No such file or directory
#include Python.h
^
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
Cleaning up...
Command /usr/bin/python -c import setuptools,
tokenize;__file__='/tmp/pip-build-gjivLQ/netifaces/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))
install --record /tmp/pip-3ffENP-record/install-record.txt
--single-version-externally-managed --compile failed with error code 1 in
/tmp/pip-build-gjivLQ/netifaces
Traceback (most recent call last):
File /usr/bin/pip, line 9, in module
load_entry_point('pip==1.5.6', 'console_scripts', 'pip')()
File /usr/lib/python2.7/dist-packages/pip/__init__.py, line 248, in main
return command.main(cmd_args)
File /usr/lib/python2.7/dist-packages/pip/basecommand.py, line 161, in
main
text = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 42:
ordinal not in range(128)
However, if I run the keystone command I get an error that debtcollector is
missing and if I then pip install it on 12.04 or 14.04 keystone then appears to
work correctly. On 15.04 this happens:
buntu@test-1504-raw:~$ sudo pip install debtcollector
sudo: unable to resolve host test-1504-raw
Traceback (most recent call last):
File /usr/bin/pip, line 9, in module
load_entry_point('pip==1.5.6', 'console_scripts', 'pip')()
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
521, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
2632, in load_entry_point
return ep.load()
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
2312, in load
return self.resolve()
File /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py, line
2318, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File /usr/lib/python2.7/dist-packages/pip/__init__.py, line 74, in
module
from pip.vcs import git, mercurial, subversion, bazaar # noqa
File /usr/lib/python2.7/dist-packages/pip/vcs/mercurial.py, line 9, in
module
from pip.download import path_to_url
File /usr/lib/python2.7/dist-packages/pip/download.py, line 25, in
module
from requests.compat import IncompleteRead
ImportError: cannot import name IncompleteRead
-mark
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1470898/+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 1212196] Re: legacy tenant terminology still used interchangeably with project
*** This bug is a duplicate of bug 1017606 *** https://bugs.launchpad.net/bugs/1017606 ** This bug has been marked a duplicate of bug 1017606 Mixing references to 'Tenants' and 'Projects' is confusing -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1212196 Title: legacy tenant terminology still used interchangeably with project Status in OpenStack Identity (Keystone): Triaged Bug description: When moving to the new version of keystone, table 'tenant' is renamed to 'project', but the information in 'extra' field of table 'user' is still using the old name 'tenantId', which confused me when I moved to the new version first time. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1212196/+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 1468248] Re: weird URLs in 'keystone-all' console log
*** This bug is a duplicate of bug 1454968 *** https://bugs.launchpad.net/bugs/1454968 ** This bug has been marked a duplicate of bug 1454968 hard to understand the uri printed in the log -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1468248 Title: weird URLs in 'keystone-all' console log Status in OpenStack Identity (Keystone): Incomplete Bug description: When 'keystone-all' is executed, weird URLs are printed in the console log. snip ... 3595 INFO keystone.common.wsgi [-] GET http://10.0.2.15:5000/v3/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy ... /snip The corresponding API call that was executed is as below: curl -v -H X-Auth-Token: xxx http://10.0.2.15:5000/v3/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1468248/+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 1467780] Re: Unused config_files parameter of service entry
** Changed in: keystone Importance: Undecided = Wishlist ** Changed in: keystone Status: In Progress = Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1467780 Title: Unused config_files parameter of service entry Status in OpenStack Identity (Keystone): Opinion Bug description: The entry of keystone service tried to provide a default config file path to load config options, but the path is unused. Actually, the oslo_config lib can automatically find default config file or automatically load the config file specified by --config-file option. So the useless code should be removed. The following is debug trace when using'keystone-manage' command with breakpoint, the other keystone service scripts is similar. it obvious that the 'config_file' parameter inputted to cli.main is None. The path of config file is impossible be /usr/etc/keystone.conf. /opt/stack/keystone/keystone/cmd/manage.py(44)main() - config_files = None (Pdb) l 39 environment.use_stdlib() 40 41 dev_conf = os.path.join(possible_topdir, 42 'etc', 43 'keystone.conf') 44 - config_files = None 45 if os.path.exists(dev_conf): 46 config_files = [dev_conf] 47 48 cli.main(argv=sys.argv, config_files=config_files) [EOF] (Pdb) p sys.argv[0] '/usr/local/bin/keystone-manage' (Pdb) p possible_topdir '/usr' (Pdb) p dev_conf '/usr/etc/keystone.conf' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1467780/+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 1464652] Re: loss of privileges of current admin user
This is by design on the keystone side. As a consequence of a reducing a user's current authorization, relevant tokens are revoked and the user must subsequently re-authenticate. If horizon stored an unscoped token along with the active scoped token, it could re-authenticate for another scoped token transparently to the end user. Because I've seen this reported a couple times over the years, I'm going to punt to Horizon this time :) ** Also affects: horizon Importance: Undecided Status: New ** 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/1464652 Title: loss of privileges of current admin user Status in OpenStack Dashboard (Horizon): New Status in OpenStack Identity (Keystone): Won't Fix Bug description: When I'm logged into openstack as the admin user into a project. I created a new project and added admin user to it and saved. Again I removed user admin from the same project and saved. Then he (admin user) looses all his admin privileges from the current session. He can't see any projects or users. We will have to log in again to re-gain the admin privileges. In detail: 1. Log in as user admin 2. Select Current Project = admin, View = admin 3. Click Projects 4. Click + Create Project 5. Name: test, Description: , Enabled: checked 6. Project Members: click the + for admin, now the admin user is added with the _member_ role 7. Click Create Project to close the dialog window 8. In the column of project test, click on Modify Users 9. Click on the - for the admin user to remove her 10. Click Save 11. An error pops up, Error: Unauthorized: Unable to retrieve project list. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464652/+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
