[Yahoo-eng-team] [Bug 1614493] Re: openstack endpoint delete failing with error not found
Per the reasons commented by Anishka, marking this as won't fix.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1614493
Title:
openstack endpoint delete failing with error not found
Status in OpenStack Identity (keystone):
Won't Fix
Bug description:
Using devstack mitaka and trying to delete endpoint
28d778c42e7644e1932023ce5807b306 created by stack.sh but its failing
with error not found while it exists.
$ openstack endpoint list
+--+---+--++
| ID | Region| Service Name | Service Type
|
+--+---+--++
| 28d778c42e7644e1932023ce5807b306 | RegionOne | neutron | network
|
| 4afd25b537b749c28344832b442d9045 | RegionOne | heat-cfn |
cloudformation |
| 4afdf9c49d534b66a2a69fef22841241 | RegionOne | heat | orchestration
|
| 07684056f1784ac6a1bdd68156ffb3fc | RegionOne | neutron | network
|
| ed180651cb1748d0bcece2a955649be4 | RegionOne | glance | image
|
| b943463cd9be4d08a729f53321f7aef6 | RegionOne | nova | compute
|
| ae99b760e89b414992795447ca9dd709 | RegionOne | nova_legacy |
compute_legacy |
| 282c0c95bc2f45a59dab9ebf4e7be84f | RegionOne | keystone | identity
|
+--+---+--++
$ openstack endpoint show 28d778c42e7644e1932023ce5807b306
+--+--+
| Field| Value|
+--+--+
| adminurl | http://192.168.2.141:9696/ |
| enabled | True |
| id | 28d778c42e7644e1932023ce5807b306 |
| internalurl | http://192.168.2.141:9696/ |
| publicurl| http://192.168.2.141:9696/ |
| region | RegionOne|
| service_id | fc163cb88651409c9d01ceb130369cdc |
| service_name | neutron |
| service_type | network |
+--+--+
$ openstack endpoint delete 28d778c42e7644e1932023ce5807b306
Could not find endpoint: 28d778c42e7644e1932023ce5807b306 (HTTP 404)
(Request-ID: req-646a9c87-2b51-4648-9875-175098e9a23b)
2016-08-18 16:52:08.195 27228 DEBUG keystone.middleware.auth
[req-646a9c87-2b51-4648-9875-175098e9a23b 2efffe9905c14da9a730c31e9e80427c
632a22881fea44e2b99adac47f43d115 - default default] RBAC: auth_context:
{'is_delegated_auth': False, 'access_token_id': None, 'user_id':
u'2efffe9905c14da9a730c31e9e80427c', 'roles': [u'admin'], 'user_domain_id':
'default', 'trustee_id': None, 'trustor_id': None, 'consumer_id': None,
'token': , 'project_id':
u'632a22881fea44e2b99adac47f43d115', 'trust_id': None, 'project_domain_id':
'default'} process_request /opt/stack/keystone/keystone/middleware/auth.py:221
2016-08-18 16:52:08.198 27228 INFO keystone.common.wsgi
[req-646a9c87-2b51-4648-9875-175098e9a23b 2efffe9905c14da9a730c31e9e80427c
632a22881fea44e2b99adac47f43d115 - default default] DELETE
http://192.168.2.141:35357/v2.0/endpoints/28d778c42e7644e1932023ce5807b306
2016-08-18 16:52:08.199 27228 DEBUG keystone.policy.backends.rules
[req-646a9c87-2b51-4648-9875-175098e9a23b 2efffe9905c14da9a730c31e9e80427c
632a22881fea44e2b99adac47f43d115 - default default] enforce admin_required:
{'user_id': u'2efffe9905c14da9a730c31e9e80427c', 'is_admin': 0, 'roles':
[u'admin'], 'tenant_id': u'632a22881fea44e2b99adac47f43d115'} enforce
/opt/stack/keystone/keystone/policy/backends/rules.py:76
2016-08-18 16:52:08.206 27228 WARNING keystone.common.wsgi
[req-646a9c87-2b51-4648-9875-175098e9a23b 2efffe9905c14da9a730c31e9e80427c
632a22881fea44e2b99adac47f43d115 - default default] Could not find endpoint:
28d778c42e7644e1932023ce5807b306
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1614493/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1672713] [NEW] Dependency between subsystems at the DB layer
Public bug reported: We should not have dependencies like foreign keys between subsystems in keystone - they might be handled by separate backends! As an example, we currently have a foreign keys between the federated_user table and protocol and idp tables [1]. We should drop this foreign keys and handle the cross-subsystems operations at the manager layer. [1] https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/094_add_federated_user_table.py#L43-L45 ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1672713 Title: Dependency between subsystems at the DB layer Status in OpenStack Identity (keystone): New Bug description: We should not have dependencies like foreign keys between subsystems in keystone - they might be handled by separate backends! As an example, we currently have a foreign keys between the federated_user table and protocol and idp tables [1]. We should drop this foreign keys and handle the cross-subsystems operations at the manager layer. [1] https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/094_add_federated_user_table.py#L43-L45 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1672713/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1662623] [NEW] Testing keystone docs are outdated
Public bug reported: Lots of things landed recently related to testing in keystone, example: a new tempest plugin, a new devstack plugin which deploys a federated environment for keystone, etc. Our docs about testing [1] don't have these recent changes and should be updated. [1] http://docs.openstack.org/developer/keystone/devref/development_best_practices.html #testing-keystone ** Affects: keystone Importance: Wishlist Assignee: Rodrigo Duarte (rodrigodsousa) Status: Confirmed ** Tags: documentation -- 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/1662623 Title: Testing keystone docs are outdated Status in OpenStack Identity (keystone): Confirmed Bug description: Lots of things landed recently related to testing in keystone, example: a new tempest plugin, a new devstack plugin which deploys a federated environment for keystone, etc. Our docs about testing [1] don't have these recent changes and should be updated. [1] http://docs.openstack.org/developer/keystone/devref/development_best_practices.html #testing-keystone To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1662623/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1660603] [NEW] Difference in Implied Roles check API return code
Public bug reported: The Implied Roles check API (HEAD /v3/roles//implies/) returns 200 in Ubuntu Trusty and 204 in Ubuntu Xenial, check the jobs results at [1] (both running latest master): - example of output in ubuntu-trusty job: http://logs.openstack.org/82/426882/1/check/gate-tempest-dsvm-neutron- full-ubuntu-trusty/d4f9ec8/console.html#_2017-01-30_20_11_54_895227 This bug is not related if returning a 200 or 204 is correct for the given API, but related to the difference between two Ubuntu versions. Additionally, this specific API doesn't use the "wsgi.render_response" method [2] - others APIs that use this method (check grant, for example) don't have this problem. [1] https://review.openstack.org/#/c/426882/ [2] https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L518-L519 ** Affects: keystone Importance: Undecided Status: New ** Description changed: The Implied Roles check API (HEAD /v3/roles//implies/) returns 200 in Ubuntu Trusty and 204 in Ubuntu Xenial, check the jobs results at [1] (both running latest master): - example of output in ubuntu-trusty job: http://logs.openstack.org/82/426882/1/check/gate-tempest-dsvm-neutron- full-ubuntu-trusty/d4f9ec8/console.html#_2017-01-30_20_11_54_895227 + This bug is not related if returning a 200 or 204 is correct for the + given API, but related to the difference between two Ubuntu versions. + Additionally, this specific API doesn't use the "wsgi.render_response" + method [2] - others APIs that use this method (check grant, for example) + don't have this problem. [1] https://review.openstack.org/#/c/426882/ - - This bug is not related if returning a 200 or 204 is correct for the - given API, but related to the difference between two Ubuntu versions. + [2] https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L518-L519 -- 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/1660603 Title: Difference in Implied Roles check API return code Status in OpenStack Identity (keystone): New Bug description: The Implied Roles check API (HEAD /v3/roles//implies/) returns 200 in Ubuntu Trusty and 204 in Ubuntu Xenial, check the jobs results at [1] (both running latest master): - example of output in ubuntu-trusty job: http://logs.openstack.org/82/426882/1/check/gate-tempest-dsvm-neutron- full-ubuntu-trusty/d4f9ec8/console.html#_2017-01-30_20_11_54_895227 This bug is not related if returning a 200 or 204 is correct for the given API, but related to the difference between two Ubuntu versions. Additionally, this specific API doesn't use the "wsgi.render_response" method [2] - others APIs that use this method (check grant, for example) don't have this problem. [1] https://review.openstack.org/#/c/426882/ [2] https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L518-L519 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1660603/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1657865] Re: It is possible to create cross domain implied roles
Although we can do something like [1], the effective role assignments will be empty because [2]. Looks like this is not a bug after all :) [1] http://paste.openstack.org/show/595788/ [2] https://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L675-L691 ** 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/1657865 Title: It is possible to create cross domain implied roles Status in OpenStack Identity (keystone): Invalid Bug description: Since we can't assign a project a role from a different domain, it is expected to not create implied roles from different domains as well. For example: * user1 * project1 - domainA * role1 - domainA * role2 - domainB * create an assignment: user1/project1/role1 If we create a rule where role1 implies role2, we would bypass the domain restriction. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1657865/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1657865] [NEW] It is possible to create cross domain implied roles
Public bug reported: Since we can't assign a project a role from a different domain, it is expected to not create implied roles from different domains as well. For example: * user1 * project1 - domainA * role1 - domainA * role2 - domainB * create an assignment: user1/project1/role1 If we create a rule where role1 implies role2, we would bypass the domain restriction. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1657865 Title: It is possible to create cross domain implied roles Status in OpenStack Identity (keystone): New Bug description: Since we can't assign a project a role from a different domain, it is expected to not create implied roles from different domains as well. For example: * user1 * project1 - domainA * role1 - domainA * role2 - domainB * create an assignment: user1/project1/role1 If we create a rule where role1 implies role2, we would bypass the domain restriction. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1657865/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1654659] [NEW] test_sql_upgrade docstring needs update
Public bug reported: Currently, the docstring at [1] states the usage of the backend_sql.conf file, which isn't used anymore in the tests of the module. Instead, the tests are using oslo.db unit tests base [2]. This doesn't mean the backend_sql.conf file isn't used anywhere else, but that it is not used anymore at test_sql_upgrade. [1] https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_sql_upgrade.py#L14-L32 [2] http://docs.openstack.org/developer/oslo.db/contributing.html#how-to-run-unit-tests ** Affects: keystone Importance: Low Status: New ** Tags: documentation low-hanging-fruit -- 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/1654659 Title: test_sql_upgrade docstring needs update Status in OpenStack Identity (keystone): New Bug description: Currently, the docstring at [1] states the usage of the backend_sql.conf file, which isn't used anymore in the tests of the module. Instead, the tests are using oslo.db unit tests base [2]. This doesn't mean the backend_sql.conf file isn't used anywhere else, but that it is not used anymore at test_sql_upgrade. [1] https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_sql_upgrade.py#L14-L32 [2] http://docs.openstack.org/developer/oslo.db/contributing.html#how-to-run-unit-tests To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1654659/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1648886] [NEW] OpenStack Identity API doc pointing to specs
Public bug reported: At keystone docs page [1], the OpenStack's Identity API link is pointing to the specs docs [2], not the API. [1] http://docs.openstack.org/developer/keystone/ [2] http://specs.openstack.org/openstack/keystone-specs/ ** Affects: keystone Importance: Undecided Status: New ** Tags: documentation -- 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/1648886 Title: OpenStack Identity API doc pointing to specs Status in OpenStack Identity (keystone): New Bug description: At keystone docs page [1], the OpenStack's Identity API link is pointing to the specs docs [2], not the API. [1] http://docs.openstack.org/developer/keystone/ [2] http://specs.openstack.org/openstack/keystone-specs/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1648886/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1645391] [NEW] mapped auth method not included by default
Public bug reported: The mapped auth method is not listed by default in keystone.conf [1]. It should be there since it is required for proper federated authentication. [1] https://github.com/openstack/keystone/blob/master/keystone/conf/constants.py#L20 ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1645391 Title: mapped auth method not included by default Status in OpenStack Identity (keystone): In Progress Bug description: The mapped auth method is not listed by default in keystone.conf [1]. It should be there since it is required for proper federated authentication. [1] https://github.com/openstack/keystone/blob/master/keystone/conf/constants.py#L20 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1645391/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1642692] [NEW] Protocol can't be deleted after federated_user is created
Public bug reported:
When authenticating a user via federation, a federated_user entry is
created in keystone's database, an example of such entry is below:
mysql> select * from federated_user;
++--+--+-+---+-+
| id | user_id | idp_id | protocol_id | unique_id
| display_name|
++--+--+-+---+-+
| 1 | 15ddf8fda20842c68b9b6d91d1a7 | testshib | mapped |
myself%40testshib.org | mys...@testshib.org |
++--+--+-+---+-+
The federated_user_protocol_id foreign key prevents the protocol
deletion:
Details: An unexpected error prevented the server from fulfilling your
request: (pymysql.err.IntegrityError) (1451, u'Cannot delete or update a
parent row: a foreign key constraint fails (`keystone`.`federated_user`,
CONSTRAINT `federated_user_protocol_id_fkey` FOREIGN KEY (`protocol_id`,
`idp_id`) REFERENCES `federation_protocol` (`id`, `idp_id`))') [SQL:
u'DELETE FROM federation_protocol WHERE federation_protocol.id = %(id)s
AND federation_protocol.idp_id = %(idp_id)s'] [parameters: {'idp_id':
u'testshib', 'id': u'mapped'}]
This can be also happening with the "idp_id" column as well.
This prevents automated tests like [1] to properly work, since it
creates and destroys the identity provider, mapping and protocol during
its execution.
[1] https://review.openstack.org/#/c/324769/
** Affects: keystone
Importance: Undecided
Assignee: Ron De Rose (ronald-de-rose)
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/1642692
Title:
Protocol can't be deleted after federated_user is created
Status in OpenStack Identity (keystone):
New
Bug description:
When authenticating a user via federation, a federated_user entry is
created in keystone's database, an example of such entry is below:
mysql> select * from federated_user;
++--+--+-+---+-+
| id | user_id | idp_id | protocol_id | unique_id
| display_name|
++--+--+-+---+-+
| 1 | 15ddf8fda20842c68b9b6d91d1a7 | testshib | mapped |
myself%40testshib.org | mys...@testshib.org |
++--+--+-+---+-+
The federated_user_protocol_id foreign key prevents the protocol
deletion:
Details: An unexpected error prevented the server from fulfilling your
request: (pymysql.err.IntegrityError) (1451, u'Cannot delete or update
a parent row: a foreign key constraint fails
(`keystone`.`federated_user`, CONSTRAINT
`federated_user_protocol_id_fkey` FOREIGN KEY (`protocol_id`,
`idp_id`) REFERENCES `federation_protocol` (`id`, `idp_id`))') [SQL:
u'DELETE FROM federation_protocol WHERE federation_protocol.id =
%(id)s AND federation_protocol.idp_id = %(idp_id)s'] [parameters:
{'idp_id': u'testshib', 'id': u'mapped'}]
This can be also happening with the "idp_id" column as well.
This prevents automated tests like [1] to properly work, since it
creates and destroys the identity provider, mapping and protocol
during its execution.
[1] https://review.openstack.org/#/c/324769/
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1642692/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1628692] [NEW] Password history constraints not enforced via /v3/users//password path
Public bug reported: Differently from the /v3/user/ route [1], the /v3/user//password is not enforcing the password history [2]. At [3] we are able to change a password that breaks the password history constraints [1] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L161 [2] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L189 [3] http://paste.openstack.org/show/583366/ ** Affects: keystone Importance: Undecided Assignee: Ron De Rose (ronald-de-rose) Status: New ** Summary changed: - Password constraints not enforced via /v3/users//password path + Password history constraints not enforced via /v3/users//password path -- 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/1628692 Title: Password history constraints not enforced via /v3/users//password path Status in OpenStack Identity (keystone): New Bug description: Differently from the /v3/user/ route [1], the /v3/user//password is not enforcing the password history [2]. At [3] we are able to change a password that breaks the password history constraints [1] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L161 [2] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L189 [3] http://paste.openstack.org/show/583366/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1628692/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1613466] [NEW] Update credential to "ec2" type accepts a credential without the project set
Public bug reported: In the credentials API schema validation [1] is mandatory to include a project when creating a credential of the "ec2" type, but we can create a credential from a different type and update it to "ec2" without providing a project [2]. [1] https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L29-L55 [2] https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L57-L62 ** Affects: keystone Importance: Undecided Status: New ** Description changed: - In the credentials API schema validation [1], it is mandatory to include - a project when creating a credential of the "ec2" type, but we can - create a credential from a different type and update it to "ec2" without + In the credentials API schema validation [1] is mandatory to include a + project when creating a credential of the "ec2" type, but we can create + a credential from a different type and update it to "ec2" without providing a project [2]. - [1] https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L29-L55 + [1] https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L29-L55 [2] https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L57-L62 -- 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/1613466 Title: Update credential to "ec2" type accepts a credential without the project set Status in OpenStack Identity (keystone): New Bug description: In the credentials API schema validation [1] is mandatory to include a project when creating a credential of the "ec2" type, but we can create a credential from a different type and update it to "ec2" without providing a project [2]. [1] https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L29-L55 [2] https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L57-L62 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1613466/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1585652] [NEW] EmptyCatalog not treated during cinderclient creation
Public bug reported:
Steps to reproduce
==
1 - Get a keystone v3 token using the ?nocatalog param. Example:
export TOKEN=`curl -i -k -v -H "Content-type: application/json" -d
'{"auth": {"identity": {"methods": ["password"], "password": {"user":
{"domain": {"name": "Default"}, "name": "test", "password":
"password"}}}, "scope": {"project": {"name": "test-project", "domain":
{"name": "Default"}' http://localhost:5000/v3/auth/tokens | grep X
-Subject-Token | awk '{print $2}' | sed -e 's,\r,,' `
2 - Try to create a server using a cinder volume. Example:
curl -k -v -H "X-Auth-Token:$TOKEN" -H "Content-type: application/json"
-d '{"server": {"name": "test_CSDPU_1", "imageRef": "",
"block_device_mapping_v2": [{"source_type": "volume",
"destination_type": "volume", "boot_index": 0, "delete_on_termination":
false, "uuid": "85397498-850f-406f-806a-25cf93cd94dc"}], "flavorRef":
"790959df-f79b-4b87-8389-a160a3b6e606", "max_count": 1, "min_count":
1}}' http://localhost:8774/v2/07564c39740f405b92f4722090cd745b/servers
Actual result
=
{"badRequest": {"message": "Block Device Mapping is Invalid: failed to
get volume 85397498-850f-406f-806a-25cf93cd94dc.", "code": 400}}
Expected result
===
Server is created without issues or a meaningful error message is
displayed.
Details
===
- During cinderclient creation, nova tries to get cinder's endpoint
using the auth object obtained from the token without the catalog [1].
keystoneauth will raise an EmptyCatalog exception [2] that is not
treated and will result in the error seen above.
[1] https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L82
[2]
https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L190
- This issue might happen in other areas of code, is not necessarily
exclusive to the cinderclient creation.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1585652
Title:
EmptyCatalog not treated during cinderclient creation
Status in OpenStack Compute (nova):
New
Bug description:
Steps to reproduce
==
1 - Get a keystone v3 token using the ?nocatalog param. Example:
export TOKEN=`curl -i -k -v -H "Content-type: application/json" -d
'{"auth": {"identity": {"methods": ["password"], "password": {"user":
{"domain": {"name": "Default"}, "name": "test", "password":
"password"}}}, "scope": {"project": {"name": "test-project", "domain":
{"name": "Default"}' http://localhost:5000/v3/auth/tokens | grep X
-Subject-Token | awk '{print $2}' | sed -e 's,\r,,' `
2 - Try to create a server using a cinder volume. Example:
curl -k -v -H "X-Auth-Token:$TOKEN" -H "Content-type:
application/json" -d '{"server": {"name": "test_CSDPU_1", "imageRef":
"", "block_device_mapping_v2": [{"source_type": "volume",
"destination_type": "volume", "boot_index": 0,
"delete_on_termination": false, "uuid": "85397498-850f-406f-806a-
25cf93cd94dc"}], "flavorRef": "790959df-f79b-4b87-8389-a160a3b6e606",
"max_count": 1, "min_count": 1}}'
http://localhost:8774/v2/07564c39740f405b92f4722090cd745b/servers
Actual result
=
{"badRequest": {"message": "Block Device Mapping is Invalid: failed to
get volume 85397498-850f-406f-806a-25cf93cd94dc.", "code": 400}}
Expected result
===
Server is created without issues or a meaningful error message is
displayed.
Details
===
- During cinderclient creation, nova tries to get cinder's endpoint
using the auth object obtained from the token without the catalog [1].
keystoneauth will raise an EmptyCatalog exception [2] that is not
treated and will result in the error seen above.
[1] https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L82
[2]
https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L190
- This issue might happen in other areas of code, is not necessarily
exclusive to the cinderclient creation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1585652/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1571878] [NEW] Add protocol to identity provider using nonexistent mapping
Public bug reported: Currently, it is possible to add a protocol to a identity provider [0] using a nonexistent mapping id. We could add a mapping later using the ID in the previous step, but several errors can occur in between this steps. We might want to enforce steps here: 1 - create idp 2 - create mapping 3 - create protocol [0] https://github.com/openstack/keystone-specs/blob/master/api/v3 /identity-api-v3-os-federation-ext.rst#add-a-protocol-and-attribute- mapping-to-an-identity-provider ** Affects: keystone Importance: Undecided Status: New ** Description changed: Currently, it is possible to add a protocol to a identity provider [0] - using a nonexistent mapping id. We could add a mapping using the ID in - the previous step, but several errors can occur in between this steps. + using a nonexistent mapping id. We could add a mapping later using the + ID in the previous step, but several errors can occur in between this + steps. We might want to enforce steps here: 1 - create idp 2 - create mapping 3 - create protocol [0] https://github.com/openstack/keystone-specs/blob/master/api/v3 /identity-api-v3-os-federation-ext.rst#add-a-protocol-and-attribute- mapping-to-an-identity-provider -- 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/1571878 Title: Add protocol to identity provider using nonexistent mapping Status in OpenStack Identity (keystone): New Bug description: Currently, it is possible to add a protocol to a identity provider [0] using a nonexistent mapping id. We could add a mapping later using the ID in the previous step, but several errors can occur in between this steps. We might want to enforce steps here: 1 - create idp 2 - create mapping 3 - create protocol [0] https://github.com/openstack/keystone-specs/blob/master/api/v3 /identity-api-v3-os-federation-ext.rst#add-a-protocol-and-attribute- mapping-to-an-identity-provider To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1571878/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1558670] [NEW] Internal server error when updating an identity provider
Public bug reported: Remote IDs for identity providers can not be reused, so during the creation of an identity provider, keystone returns a 409 Conflict when we try to do so. However, the same problem occurs when updating an identity provider and using a remote ID from another registered identity provider, but the duplicate entry error is not treated and a HTTP 500 is returned. Error trace: http://paste.openstack.org/show/490946/ ** Affects: keystone Importance: Undecided Status: New ** Description changed: Remote IDs for identity providers can not be reused, so during the creation of an identity provider, keystone returns a 409 Conflict when we try to do so. However, the same problem occurs when updating an identity provider and using a remote ID from another registered identity provider, but the duplicate entry error is not treated and a HTTP 500 is returned. - See the trace error: http://paste.openstack.org/show/490946/ + Error trace: http://paste.openstack.org/show/490946/ -- 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/1558670 Title: Internal server error when updating an identity provider Status in OpenStack Identity (keystone): New Bug description: Remote IDs for identity providers can not be reused, so during the creation of an identity provider, keystone returns a 409 Conflict when we try to do so. However, the same problem occurs when updating an identity provider and using a remote ID from another registered identity provider, but the duplicate entry error is not treated and a HTTP 500 is returned. Error trace: http://paste.openstack.org/show/490946/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1558670/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1425108] Re: private _get_children() in sql backend doesn't support passing None values
This is not a valid situation anymore. ** 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/1425108 Title: private _get_children() in sql backend doesn't support passing None values Status in OpenStack Identity (keystone): Invalid 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 1459686] [NEW] Give more details about the K2K flow
Public bug reported: Currently, the K2K flow in the config file [1] isn't detailed enough, we should provide at least the next step where we exchange a SAML assertion for a unscoped token from the SP. [1] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst #testing-it-all-out ** Affects: keystone Importance: Undecided Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459686 Title: Give more details about the K2K flow Status in OpenStack Identity (Keystone): New Bug description: Currently, the K2K flow in the config file [1] isn't detailed enough, we should provide at least the next step where we exchange a SAML assertion for a unscoped token from the SP. [1] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst #testing-it-all-out To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459686/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1459683] [NEW] Config federation docs still references SP as regions
Public bug reported: In the session [1], SPs are still referenced as regions. [1] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst #testing-it-all-out ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) Status: In Progress ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459683 Title: Config federation docs still references SP as regions Status in OpenStack Identity (Keystone): In Progress Bug description: In the session [1], SPs are still referenced as regions. [1] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst #testing-it-all-out To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459683/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1459279] [NEW] Wrong assertion examples in doc
Public bug reported: The "pure" SAML assertion example in [1] is not a valid assertion generated by keystone and the ECP wrapped one is missing the two new attributes "openstack_user_domain" and "openstack_project_domain". [1] https://github.com/openstack/keystone-specs/blob/master/api/v3 /identity-api-v3-os-federation-ext.rst#generating-assertions ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) Status: In Progress ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459279 Title: Wrong assertion examples in doc Status in OpenStack Identity (Keystone): In Progress Bug description: The "pure" SAML assertion example in [1] is not a valid assertion generated by keystone and the ECP wrapped one is missing the two new attributes "openstack_user_domain" and "openstack_project_domain". [1] https://github.com/openstack/keystone-specs/blob/master/api/v3 /identity-api-v3-os-federation-ext.rst#generating-assertions To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459279/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1459255] [NEW] Fix the docs since Federation is no longer an extension
Public bug reported: Currently we have a documentation to enable the Federation extension [1]. Although there is some steps that are no longer needed, some of them need to be executed in order to the functionality properly work: add the "saml2" auth method, install xmlsec1 and pysaml2. These steps should be included in the main Federation doc [2] and the extension one should be removed. [1] https://github.com/openstack/keystone/blob/master/doc/source/extensions/federation.rst [2] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst ** Affects: keystone Importance: Undecided Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459255 Title: Fix the docs since Federation is no longer an extension Status in OpenStack Identity (Keystone): New Bug description: Currently we have a documentation to enable the Federation extension [1]. Although there is some steps that are no longer needed, some of them need to be executed in order to the functionality properly work: add the "saml2" auth method, install xmlsec1 and pysaml2. These steps should be included in the main Federation doc [2] and the extension one should be removed. [1] https://github.com/openstack/keystone/blob/master/doc/source/extensions/federation.rst [2] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459255/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1457279] Re: keystoneclient cannot log non-ascii data
This should be targeted to python-keystoneclient
** Project changed: keystone => python-keystoneclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1457279
Title:
keystoneclient cannot log non-ascii data
Status in Python client library for Keystone:
New
Bug description:
In keystoneclient/session.py file, _http_log_request method, we have below
codes:
if data:
string_parts.append("-d '%s'" % data)
logger.debug(' '.join(string_parts))
However, if data is not in ascii chars, this might cause error like:
UnicodeEncodeError: 'ascii' codec can't encode character u'\\xbb' in position
10: ordinal not in range(128)
This is also the reason of bug https://bugs.launchpad.net/horizon/+bug/1453953
To manage notifications about this bug go to:
https://bugs.launchpad.net/python-keystoneclient/+bug/1457279/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1442787] [NEW] Mapping openstack_user attribute in k2k assertions with different domains
Public bug reported: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): New Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1438915] [NEW] Delete domain operation may have atomicity problems
Public bug reported: This bug was first discussed in the Recursive Deletion spec: https://review.openstack.org/#/c/148730/ Currently, when deleting a domain, all projects inside that domain are also deleted. When we have a hierarchy of projects this may cause inconsistencies since the operations are not atomic [1] (each level of the hierarchy is deleted in a separate transaction). Two possible solutions to explore are: 1 - Use the concept of logical deletion 2 - As a first step list all project's id to be deleted and trigger one delete transaction with all ids [1] https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L470-L498 ** Affects: keystone Importance: Undecided Status: New ** Description changed: + This bug was first discussed in the Recursive Deletion spec: + https://review.openstack.org/#/c/148730/ + Currently, when deleting a domain, all projects inside that domain are also deleted. When we have a hierarchy of projects this may cause inconsistencies since the operations are not atomic [1] (each level of the hierarchy is deleted in a separate transaction). Two possible solutions to explore are: 1 - Use the concept of logical deletion 2 - As a first step list all project's id to be deleted and trigger one delete transaction with all ids [1] https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L470-L498 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1438915 Title: Delete domain operation may have atomicity problems Status in OpenStack Identity (Keystone): New Bug description: This bug was first discussed in the Recursive Deletion spec: https://review.openstack.org/#/c/148730/ Currently, when deleting a domain, all projects inside that domain are also deleted. When we have a hierarchy of projects this may cause inconsistencies since the operations are not atomic [1] (each level of the hierarchy is deleted in a separate transaction). Two possible solutions to explore are: 1 - Use the concept of logical deletion 2 - As a first step list all project's id to be deleted and trigger one delete transaction with all ids [1] https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L470-L498 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1438915/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1435487] [NEW] ServiceProviderModel has wrong attributes for auth_url and sp_url
Public bug reported: The attributes aren't nullable [1], but in the ServiceProviderModel they have nullable=True [2]. [1] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/migrate_repo/versions/006_fixup_service_provider_attributes.py#L39-L40 [2] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/backends/sql.py#L97-L98 ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) 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/1435487 Title: ServiceProviderModel has wrong attributes for auth_url and sp_url Status in OpenStack Identity (Keystone): In Progress Bug description: The attributes aren't nullable [1], but in the ServiceProviderModel they have nullable=True [2]. [1] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/migrate_repo/versions/006_fixup_service_provider_attributes.py#L39-L40 [2] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/backends/sql.py#L97-L98 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1435487/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1434643] [NEW] missing parent_id filter in the API spec for list projects
Public bug reported: Filter by the parent_id is already supported in the code [1], this should be documented in the API spec. [1] https://github.com/openstack/keystone/blob/master/keystone/resource/controllers.py#L210 ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) Status: In Progress ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1434643 Title: missing parent_id filter in the API spec for list projects Status in OpenStack Identity (Keystone): In Progress Bug description: Filter by the parent_id is already supported in the code [1], this should be documented in the API spec. [1] https://github.com/openstack/keystone/blob/master/keystone/resource/controllers.py#L210 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1434643/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1431377] [NEW] service provider object accepts null values for mandatory fields
Public bug reported: the auth_url and sp_url fields are mandatory in order to provide federated authentication in keystone-to-keystone [1], both fields can be nullable in the service provider database [2]. it is also needed to add this validation in the json schema. [1] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L339 [2] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/migrate_repo/versions/005_add_service_provider_table.py#L23-L27 ** Affects: keystone Importance: Low Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1431377 Title: service provider object accepts null values for mandatory fields Status in OpenStack Identity (Keystone): Confirmed Bug description: the auth_url and sp_url fields are mandatory in order to provide federated authentication in keystone-to-keystone [1], both fields can be nullable in the service provider database [2]. it is also needed to add this validation in the json schema. [1] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L339 [2] https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/migrate_repo/versions/005_add_service_provider_table.py#L23-L27 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1431377/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1428124] [NEW] Missing tests to list projects by the parent_id
Public bug reported: Although it is possible to perform GET /projects?parent_id= [1], it is not tested. [1] https://github.com/openstack/keystone/blob/master/keystone/resource/controllers.py#L167 ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) Status: In Progress ** Tags: 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/1428124 Title: Missing tests to list projects by the parent_id Status in OpenStack Identity (Keystone): In Progress Bug description: Although it is possible to perform GET /projects?parent_id= [1], it is not tested. [1] https://github.com/openstack/keystone/blob/master/keystone/resource/controllers.py#L167 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428124/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1426496] [NEW] Create project with invalid domain_id
Public bug reported: Right now it is possible to create a project with an invalid domain_id (we do not check if the domain_id exists in the create_project method): https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L87-L116 ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) 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/1426496 Title: Create project with invalid domain_id Status in OpenStack Identity (Keystone): In Progress Bug description: Right now it is possible to create a project with an invalid domain_id (we do not check if the domain_id exists in the create_project method): https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L87-L116 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1426496/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1425113] [NEW] list_projects_in_subtree() and list_project_parents() accepts invalid values
Public bug reported: The list_projects_in_subtree() and list_project_parents() method accepts invalid values of project_id (such as None and non-existent project_ids). ** Affects: keystone Importance: Undecided Status: New ** Summary changed: - list_projects_in_subtree() accepts invalid values + list_projects_in_subtree() and list_project_parents() accepts invalid values ** Description changed: - The list_projects_in_subtree() method accepts invalid values of - project_id (such as None and non-existent project_ids). + The list_projects_in_subtree() and list_project_parents() method accepts + invalid values of project_id (such as None and non-existent + project_ids). -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1425113 Title: list_projects_in_subtree() and list_project_parents() accepts invalid values Status in OpenStack Identity (Keystone): New Bug description: The list_projects_in_subtree() and list_project_parents() method accepts invalid values of project_id (such as None and non-existent project_ids). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1425113/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1425108] [NEW] private _get_children() in sql backend doesn't support passing None values
Public bug reported: 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 ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1425108 Title: private _get_children() in sql backend doesn't support passing None values Status in OpenStack Identity (Keystone): New 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 1420791] Re: python keystoneclient misreports connection error reason
Redirecting to python-keystoneclient. ** Project changed: keystone => python-keystoneclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1420791 Title: python keystoneclient misreports connection error reason Status in Python client library for Keystone: New Bug description: The python keystoneclient reports a set of connection errors as "Connection refused", except connection refused itself: https://github.com/openstack/python- keystoneclient/blob/a333c56ac9a6b48b8e5d16e654251fb7d15bd89f/keystoneclient/session.py#L411 This can make tracking down authentication and connection problems difficult without using a tool like strace. To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1420791/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1418837] Re: [Document Bug] credential set not work as help document (optional parameters actually required) - openstackcli
Hi, this seems as an openstackclient bug, will change the target.
** 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/1418837
Title:
[Document Bug] credential set not work as help document (optional
parameters actually required) - openstackcli
Status in OpenStack Command Line Client:
New
Bug description:
(openstack) credential set -h
usage: credential set [-h] [--user ] [--type ] [--data ]
[--project ]
Set credential command
positional arguments:
ID of credential to change
optional arguments:
-h, --help show this help message and exit
--user Name or ID of user that owns the credential
--type New credential type
--data New credential data
--project Project name or ID which limits the scope of the
credential
(openstack) credential set
50002651b7c5887a081b74b80fa0586a493857008c611c1b1e3a25c09d34e0cd --project admin
ERROR: openstack update() takes at least 3 arguments (3 given)
(openstack) credential set
50002651b7c5887a081b74b80fa0586a493857008c611c1b1e3a25c09d34e0cd --type ec2
--user apal-test --project apal-test
ERROR: openstack Credential requires blob to be specified
(openstack) credential set
50002651b7c5887a081b74b80fa0586a493857008c611c1b1e3a25c09d34e0cd --type ec2
--user apal-test --project apal-test --data "
{\"access\": \"testbfec279f1e904166a864bb0a4c4432ac\", \"secret\":
\"7fd9c120d7f44bc7a491b08cf7792fedtset\"}
"
(openstack) (test_venv)cetest@cer106n0035:~$
To manage notifications about this bug go to:
https://bugs.launchpad.net/python-openstackclient/+bug/1418837/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1411625] Re: Keystone not throwing any exception when there is no proper OS credentails.
** Project changed: keystone => python-keystoneclient ** Description changed: When we miss any of the environment variable, Keystone commands do not throw any error, it just simply output nothing. But when when we run - nova command it outputs proper error message. So similarly even keystone - should throw appropriate error message when any of the environment - variable is missing. + nova client command it outputs proper error message. So similarly even + keystone client should throw appropriate error message when any of the + environment variable is missing. Steps to reproduce. root@ubuntu:~# unset OS_TENANT_NAME root@ubuntu:~# keystone user-list root@ubuntu:~# nova list ERROR (CommandError): You must provide a tenant name or tenant id via --os-tenant-name, --os-tenant-id, env[OS_TENANT_NAME] or env[OS_TENANT_ID] root@ubuntu:~# ** Summary changed: - Keystone not throwing any exception when there is no proper OS credentails. + Keystone client (command line) not throwing any exception when there is no proper OS credentails. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1411625 Title: Keystone client (command line) not throwing any exception when there is no proper OS credentails. Status in Python client library for Keystone: New Bug description: When we miss any of the environment variable, Keystone commands do not throw any error, it just simply output nothing. But when when we run nova client command it outputs proper error message. So similarly even keystone client should throw appropriate error message when any of the environment variable is missing. Steps to reproduce. root@ubuntu:~# unset OS_TENANT_NAME root@ubuntu:~# keystone user-list root@ubuntu:~# nova list ERROR (CommandError): You must provide a tenant name or tenant id via --os-tenant-name, --os-tenant-id, env[OS_TENANT_NAME] or env[OS_TENANT_ID] root@ubuntu:~# To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1411625/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1397318] [NEW] Wront return code for inherited role checking
Public bug reported:
As per https://github.com/openstack/keystone-specs/blob/master/api/v3
/identity-api-v3-os-inherit-ext.rst#check-if-user-has-an-inherited-
project-role-on-domain, HEAD /OS-
INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects
returns "204 No Content", but the correct return is "200":
curl --verbose -X HEAD -H "X-Auth-Token:$TOKEN"
"http://localhost:5000/v3/OS-INHERIT/domains/default/users/dd55a1c1c05842c29b50ef8ecce681a7/roles/inherited_to_projects";
* Hostname was NOT found in DNS cache
* Trying 127.0.1.1...
* Connected to localhost (127.0.1.1) port 5000 (#0)
> HEAD
> /v3/OS-INHERIT/domains/default/users/dd55a1c1c05842c29b50ef8ecce681a7/roles/inherited_to_projects
> HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:5000
> Accept: */*
> X-Auth-Token:9c87d13fa15d41549f634bd06f4551b4
>
< HTTP/1.1 200 OK
< Date: Fri, 28 Nov 2014 12:59:10 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< Vary: X-Auth-Token
< Content-Length: 334
< Content-Type: application/json
** Affects: keystone
Importance: Undecided
Assignee: Rodrigo Duarte (rodrigodsousa)
Status: In Progress
** Tags: documentation 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/1397318
Title:
Wront return code for inherited role checking
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
As per https://github.com/openstack/keystone-specs/blob/master/api/v3
/identity-api-v3-os-inherit-ext.rst#check-if-user-has-an-inherited-
project-role-on-domain, HEAD /OS-
INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects
returns "204 No Content", but the correct return is "200":
curl --verbose -X HEAD -H "X-Auth-Token:$TOKEN"
"http://localhost:5000/v3/OS-INHERIT/domains/default/users/dd55a1c1c05842c29b50ef8ecce681a7/roles/inherited_to_projects";
* Hostname was NOT found in DNS cache
* Trying 127.0.1.1...
* Connected to localhost (127.0.1.1) port 5000 (#0)
> HEAD
/v3/OS-INHERIT/domains/default/users/dd55a1c1c05842c29b50ef8ecce681a7/roles/inherited_to_projects
HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:5000
> Accept: */*
> X-Auth-Token:9c87d13fa15d41549f634bd06f4551b4
>
< HTTP/1.1 200 OK
< Date: Fri, 28 Nov 2014 12:59:10 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< Vary: X-Auth-Token
< Content-Length: 334
< Content-Type: application/json
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1397318/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1395117] [NEW] Create SAML assertion using domain scoped tokens returns 500 (Internal Server Error)
Public bug reported: When using a domain scoped token to request a SAML assertion, Keystone responds with a Internal Server Error. Here is where this condition is handled: https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L279 ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1395117 Title: Create SAML assertion using domain scoped tokens returns 500 (Internal Server Error) Status in OpenStack Identity (Keystone): New Bug description: When using a domain scoped token to request a SAML assertion, Keystone responds with a Internal Server Error. Here is where this condition is handled: https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L279 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1395117/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1392845] [NEW] API spec describes the wrong behaviour to enable/disable projects considering a projects hierarhcy
Public bug reported: The doc is missing the enable project behaviour (only allow to enable a project that has enabled parents) and contains a wrong behaviour at the disable projects part: https://github.com/openstack/keystone- specs/blob/master/api/v3/identity-api-v3.rst#update-project since we will be able to disable a project once its full subtree is disabled. ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) 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/1392845 Title: API spec describes the wrong behaviour to enable/disable projects considering a projects hierarhcy Status in OpenStack Identity (Keystone): In Progress Bug description: The doc is missing the enable project behaviour (only allow to enable a project that has enabled parents) and contains a wrong behaviour at the disable projects part: https://github.com/openstack/keystone- specs/blob/master/api/v3/identity-api-v3.rst#update-project since we will be able to disable a project once its full subtree is disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1392845/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1384382] [NEW] GET /OS-FEDERATION/saml2/metadata does not work
Public bug reported:
In Kestone-to-Keystone federation, the metadata from Keystone Identity
Provider needs to be exchanged with the Keystone Service Provider. This
is done via the GET /OS-FEDERATION/saml2/metadata endpoint, which is
returning an internal server error (500).
Looking in the log files, seems that keystone.middleware.core is trying
to parse the XML body into JSON, which fails:
2014-10-22 18:15:32.177590 20576 DEBUG keystone.common.wsgi [-] arg_dict: {}
__call__ /opt/stack/keystone/keystone/common/wsgi.py:191
2014-10-22 18:15:32.184124 20576 ERROR keystone.middleware.core [-] Serializer
failed
2014-10-22 18:15:32.184148 20576 TRACE keystone.middleware.core Traceback (most
recent call last):
2014-10-22 18:15:32.184155 20576 TRACE keystone.middleware.core File
"/opt/stack/keystone/keystone/middleware/core.py", line 183, in process_response
2014-10-22 18:15:32.184168 20576 TRACE keystone.middleware.core body_obj =
jsonutils.loads(response.body)
2014-10-22 18:15:32.184185 20576 TRACE keystone.middleware.core File
"/usr/local/lib/python2.7/dist-packages/oslo/serialization/jsonutils.py", line
211, in loads
2014-10-22 18:15:32.184194 20576 TRACE keystone.middleware.core return
json.loads(encodeutils.safe_decode(s, encoding), **kwargs)
2014-10-22 18:15:32.184201 20576 TRACE keystone.middleware.core File
"/usr/lib/python2.7/json/__init__.py", line 338, in loads
2014-10-22 18:15:32.184207 20576 TRACE keystone.middleware.core return
_default_decoder.decode(s)
2014-10-22 18:15:32.184213 20576 TRACE keystone.middleware.core File
"/usr/lib/python2.7/json/decoder.py", line 366, in decode
2014-10-22 18:15:32.184220 20576 TRACE keystone.middleware.core obj, end =
self.raw_decode(s, idx=_w(s, 0).end())
2014-10-22 18:15:32.184226 20576 TRACE keystone.middleware.core File
"/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
2014-10-22 18:15:32.184232 20576 TRACE keystone.middleware.core raise
ValueError("No JSON object could be decoded")
2014-10-22 18:15:32.184238 20576 TRACE keystone.middleware.core ValueError: No
JSON object could be decoded
2014-10-22 18:15:32.184244 20576 TRACE keystone.middleware.core
2014-10-22 18:15:32.184740 20576 WARNING keystone.common.wsgi [-]
2014-10-22 18:15:32.184765 http://www.w3.org/2000/09/xmldsig#";
entityID="http://localhost:5000/v3/OS-FEDERATION/saml2/idp";>...rodrigodsrodrigodslocalhostrodrigodsRodrigoDuarterodrigodso...@gmail.com555-55-urn:oasis:names:tc:SAML:2.0:nameid-format:transienthttp://localhost:5000/v3/OS-FEDERATION/saml2/sso";
/>
** Affects: keystone
Importance: Undecided
Assignee: Rodrigo Duarte (rodrigodsousa)
Status: New
** Changed in: keystone
Assignee: (unassigned) => Rodrigo Duarte (rodrigodsousa)
** Description changed:
In Kestone-to-Keystone federation, the metadata from Keystone Identity
Provider needs to be exchanged with the Keystone Service Provider. This
is done via the GET /OS-FEDERATION/saml2/metadata endpoint, which is
returning an internal server error (500).
Looking in the log files, seems that keystone.middleware.core is trying
to parse the XML body into JSON, which fails:
2014-10-22 18:15:32.177590 20576 DEBUG keystone.common.wsgi [-] arg_dict: {}
__call__ /opt/stack/keystone/keystone/common/wsgi.py:191
2014-10-22 18:15:32.184124 20576 ERROR keystone.middleware.core [-]
Serializer failed
2014-10-22 18:15:32.184148 20576 TRACE keystone.middleware.core Traceback
(most recent call last):
2014-10-22 18:15:32.184155 20576 TRACE keystone.middleware.core File
"/opt/stack/keystone/keystone/middleware/core.py", line 183, in process_response
2014-10-22 18:15:32.184168 20576 TRACE keystone.middleware.core body_obj
= jsonutils.loads(response.body)
2014-10-22 18:15:32.184185 20576 TRACE keystone.middleware.core File
"/usr/local/lib/python2.7/dist-packages/oslo/serialization/jsonutils.py", line
211, in loads
2014-10-22 18:15:32.184194 20576 TRACE keystone.middleware.core return
json.loads(encodeutils.safe_decode(s, encoding), **kwargs)
2014-10-22 18:15:32.184201 20576 TRACE keystone.middleware.core File
"/usr/lib/python2.7/json/__init__.py", line 338, in loads
2014-10-22 18:15:32.184207 20576 TRACE keystone.middleware.core return
_default_decoder.decode(s)
2014-10-22 18:15:32.184213 20576 TRACE keystone.middleware.core File
"/usr/lib/python2.7/json/decoder.py", line 366, in decode
2014-10-22 18:15:32.184220 20576 TRACE keystone.middleware.core obj, end
= self.raw_decode(s, idx=_w(s, 0).end())
2014-10-22 18:15:32.184226 20576 TRACE keystone.middleware.core File
"/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
2014-10-22 18:15:32.184232 20576 TRACE keystone.middleware.core raise
ValueError("No JSON object could be decoded")
[Yahoo-eng-team] [Bug 1382906] Re: pipe not closed with use of popen
** 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/1382906 Title: pipe not closed with use of popen Status in OpenStack Identity (Keystone): Invalid Status in Python client library for Keystone: In Progress Bug description: In keystoneclient.common.cms, subprocess.Popen is used to get the output of openssl execution. After running keystone for a while, there are many open pipes and eventually causing keystone to stop working because of open file limit. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1382906/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1369137] [NEW] LIsting groups roles performance
Public bug reported: In UpdateProjectGroupsAction, is done a call to every group in a project to get their roles: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/identity/projects/workflows.py#L313. With Identity V3 API, it's possible to get this information using a single API call: GET v3/role_assignments?group.id=&scope.project.id= This issue is similar to bug #1278920. ** Affects: horizon Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => Rodrigo Duarte (rodrigodsousa) ** Changed in: horizon Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1369137 Title: LIsting groups roles performance Status in OpenStack Dashboard (Horizon): In Progress Bug description: In UpdateProjectGroupsAction, is done a call to every group in a project to get their roles: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/identity/projects/workflows.py#L313. With Identity V3 API, it's possible to get this information using a single API call: GET v3/role_assignments?group.id=&scope.project.id= This issue is similar to bug #1278920. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369137/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
