[Yahoo-eng-team] [Bug 1652012] [NEW] token model assumes a token is is_admin_project
Public bug reported: Our token model code will return a default of True for is_admin_project if that attribute is not defined. The comment next to this says this is for backward compatibility - but this seems inherently dangerous. We should investigate what changes are needed (if any) to make the default False. ** 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/1652012 Title: token model assumes a token is is_admin_project Status in OpenStack Identity (keystone): New Bug description: Our token model code will return a default of True for is_admin_project if that attribute is not defined. The comment next to this says this is for backward compatibility - but this seems inherently dangerous. We should investigate what changes are needed (if any) to make the default False. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1652012/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1651989] [NEW] domain admin token will be treated as cloud admin
Public bug reported: The new capability of is_admin_project is currently only supported for projects. However, the existing code for token models will return is_admin_project as True if the attribute has not been set. Hence admin domain tokens might get interpreted as cloud admin tokens. This is currently masked by a bug in our policy samples that do not correctly check for is_admin_project. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1651989 Title: domain admin token will be treated as cloud admin Status in OpenStack Identity (keystone): New Bug description: The new capability of is_admin_project is currently only supported for projects. However, the existing code for token models will return is_admin_project as True if the attribute has not been set. Hence admin domain tokens might get interpreted as cloud admin tokens. This is currently masked by a bug in our policy samples that do not correctly check for is_admin_project. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1651989/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1640483] Re: list of inherited role assignments to a project hierarchy does not contain the assignee/root project for users
This appears to be working as designed. Inherited assignments are only
applied to the children of the anchor point. Hence there are no
effective assignments on P.
** 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/1640483
Title:
list of inherited role assignments to a project hierarchy does not
contain the assignee/root project for users
Status in OpenStack Identity (keystone):
Invalid
Bug description:
Hi all,
I have a role R, group G with user U and a project P with a child project CP.
If I call:
(1) PUT
/v3/OS-INHERIT/projects/P_id/groups/G_id/roles/R_id/inherited_to_projects
and validate it with:
(2)HEAD
/v3/OS-INHERIT/projects/P_id/groups/G_id/roles/R_id/inherited_to_projects
everything seems to be fine.
But if I query the user role assignments in scope of P
(3) GET /v3/role_assignments?scope.project.id=P_id=U_id
result list is empty.
If I change the scope param to the child project id:
(4) GET GET
/v3/role_assignments?scope.project.id=CP_id=U_id
I get one role assignment list:
{
"role_assignments": [
{
"scope": {
"project": {
"id": "CP_id"
},
"OS-INHERIT:inherited_to": "projects"
},
"role": {
"id": "R_id"
},
"user": {
"id": "U_id"
},
"links": {
"assignment":
".../v3/OS-INHERIT/projects/P_id/groups/G_id/roles/R_id/inherited_to_projects",
"membership": ".../v3/groups/G_id/users/U_id"
}
My questions:
- did I understand wrong the sentence
"The inherited role assignment is anchored to a project and applied to its
subtree in the projects hierarchy (both existing and future projects)." resp.
its "anchored to a project"
(http://developer.openstack.org/api-
ref/identity/v3/index.html?expanded=list-effective-role-assignments-
detail,list-domains-detail,list-user-s-inherited-project-roles-on-
project-detail,assign-role-to-group-on-projects-owned-by-a-domain-
detail,assign-role-to-group-on-projects-in-a-subtree-detail#)
- Why there is no role assignment to P created by (1)? Is P not the
part of inheritance?
I think it is a bug.
Regards
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1640483/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1615698] [NEW] developing.rst needs to be updated for new rolling upgrade approach
Public bug reported: The existing developing.rst references the standard rolling upgrade approach where contract can't remove anything until X+2 etc. This needs to be updated for the new approach we have now merged. ** Affects: keystone Importance: Undecided Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Assignee: (unassigned) => Henry Nash (henry-nash) -- 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/1615698 Title: developing.rst needs to be updated for new rolling upgrade approach Status in OpenStack Identity (keystone): New Bug description: The existing developing.rst references the standard rolling upgrade approach where contract can't remove anything until X+2 etc. This needs to be updated for the new approach we have now merged. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1615698/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1604479] Re: tenantId/default_project_id missing on Keystone service user in Mitaka
Hi I think the puppet change is the right thing, I don't think there will be much support for changing the keystone design here. ** 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/1604479 Title: tenantId/default_project_id missing on Keystone service user in Mitaka Status in OpenStack Identity (keystone): Invalid Bug description: On upgrading to Mitaka, we saw that the user ref in Keystone does not have a tenantId or default_project_id field. This breaks: 1) The Detailed view in Horizon in the Identity pane where ProjectID is shown as "None" 2) any services project based RBAC policies that we have in place. Noticed a new local_user DB table for all the services users (no project/tenantId field in here): keystone=# select * from local_user; id | user_id | domain_id |name +--+---+ 1 | 3c1bd8c0f6324dcc938900d8eb801aa5 | default | admin 2 | d1c4f7a244f74892b612b9b2ded6d602 | default | neutron 3 | a481a1f43ec0463083b7a30d20493d38 | default | nova 4 | 951068b3372f47ac827ade8f67cc19b4 | default | glance 6 | 4b76763e375946998445b65b11c8db73 | default | ceilometer 7 | 15c8e1e463cc4370ad369eaf8504b727 | default | cinder 8 | 5c3ea23eb8e14070bc562951bb266073 | default | sysinv 9 | 2b62ced877244e74ba90b546225740d0 | default | heat 10 | 5a506282b45c4064b262f3f414f1f699 | default | kam (9 rows) Note that an admin role is assigned for these services users in the services project. It is just not present within the user reference or keystone user-get: $ keystone user-role-list +--+---+--+--+ |id| name | user_id |tenant_id | +--+---+--+--+ | f9985117736b4684904b4eb55476f30a | admin | a481a1f43ec0463083b7a30d20493d38 | c211dda10c9a4b2db16f239dccf65acd | +--+---+--+--+ $ keystone user-get +--+--+ | Property | Value | +--+--+ | email | nova@localhost | | enabled | True | |id| a481a1f43ec0463083b7a30d20493d38 | | name | nova | | username | nova | +--+--+ Contrast this to Kilo/Liberty where tenantId is visible within user reference: $ keystone user-get b7a3bcd588b5482ab9741efcf3f9bb33 +--+--+ | Property | Value | +--+--+ | email | nova@localhost | | enabled | True | |id| b7a3bcd588b5482ab9741efcf3f9bb33 | | name | nova | | tenantId | 2e4a21e1a37840879321320107c74f86 | << | username | nova | +--+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1604479/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1607114] [NEW] List role assignments doesn't include domain of role
Public bug reported: The list role assignment will return the names (and domain names) of each party in an assignment if the the "include_names" query parameter is included. However, this is not true for roles, which would be useful for domain specific roles. ** Affects: keystone Importance: Undecided Status: New ** Description changed: The list role assignment will return the names (and domain names) of each party in an assignment if the the "include_names" query parameter is included. - However, this is not true for domain specific roles. + However, this is not true for roles, which would be useful for domain + specific roles. -- 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/1607114 Title: List role assignments doesn't include domain of role Status in OpenStack Identity (keystone): New Bug description: The list role assignment will return the names (and domain names) of each party in an assignment if the the "include_names" query parameter is included. However, this is not true for roles, which would be useful for domain specific roles. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1607114/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1596500] [NEW] Passwords created_at attribute could remain unset during rolling upgrade
Public bug reported: Migrate 105 (in Newton) adds the password created_at attribute, and defaults it to now(). However, this is not a server default, rather it is a "write to all existing rows" at the time the DB is migrated. The following rolling upgrade sequence will cause this to remain unset: 1) Imagine a 2 node Mitaka keystone configuration (node A and b), sharing a DB 2) A rolling upgrade is started, and node A is upgrade to Newton, which will migrate the shared DB 3) Before node B can be upgraded, a new user is created with a password via node B. Since this is not running the new Newton code, the code will not know to set the created_at attribute 4) Node B is upgraded to Newton, but this will leave the user record still with created_at as None The preferred solution would be to have a keystone_manage "rolling upgrade completion" step, which would check the DB for any rows that did not have the correct defaults set (i.e. where added during the rolling migration). ** 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/1596500 Title: Passwords created_at attribute could remain unset during rolling upgrade Status in OpenStack Identity (keystone): New Bug description: Migrate 105 (in Newton) adds the password created_at attribute, and defaults it to now(). However, this is not a server default, rather it is a "write to all existing rows" at the time the DB is migrated. The following rolling upgrade sequence will cause this to remain unset: 1) Imagine a 2 node Mitaka keystone configuration (node A and b), sharing a DB 2) A rolling upgrade is started, and node A is upgrade to Newton, which will migrate the shared DB 3) Before node B can be upgraded, a new user is created with a password via node B. Since this is not running the new Newton code, the code will not know to set the created_at attribute 4) Node B is upgraded to Newton, but this will leave the user record still with created_at as None The preferred solution would be to have a keystone_manage "rolling upgrade completion" step, which would check the DB for any rows that did not have the correct defaults set (i.e. where added during the rolling migration). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1596500/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1583142] Re: Roles inheritance for groups is not visible in user's role assignments
This bug is invalid, since: 1) Inheritance is only applied to children of the node that carries the actual inherited assignment 2) Effective assignments only show the result of all group & inherited assignments, as well as valid non-inedited direct user assignments - but do not include the source assignments that generate these results The "inherit only on children" comes from the heritage of inheritance, which was originally designed to only be placed on domains, and all the projects in the domain would get the assignment. We considered changing this for project-project inheritance, but decided it would be too confusing to have two types of inheritance rules. If in the above example, you also want there user to have a role on PR-A, then you need to have a second (non-inherited) assignment (either for the user of the group) on PR-A ** 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/1583142 Title: Roles inheritance for groups is not visible in user's role assignments Status in OpenStack Identity (keystone): Invalid Bug description: If I applied role inheritance to a group GR-A in scope of project PR-A: (PUT) /v3/OS- INHERIT/projects/PR-A/groups/GR-A/roles/ROLE-A/inherited_to_projects this role assignment is listed in the result of: (GET) /v3/role_assignments?scope.project.id=PR-A=GR-A but is not in the result of: (GET) /v3/role_assignments?scope.project.id=PR-A=USR-A whereby USR-A is a member of the group GR-A. BUT it is part of result of the query: (GET) /v3/role_assignments?scope.project.id=SUB- PR-A=USR-A whereby SUB-PR-A is a child of PR-A. I think the inherited roles assignment should be valid in the project scope of PR-A for both groups and users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1583142/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1586289] Re: openstack project list can not list the project which is domain.
Ah, damn! Looks like the openstackclient has not been updated either!
OK, I'll have to fix that. What I would expect you to be able to do
(once I've fixed, which I will do asap), will be to issue a command
like:
openstack project list --is_domain
In the meantime, if you want to experiment, you could fire the raw http
command at your keystone server (using curl of whatever), e.g.:
curl -s \
-H "X-Auth-Token: $OS_TOKEN" \
http://localhost:5000/v3/projects?is_domain | python -mjson.tool
where OS_TOKEN contains your project scoped token ID and localhost is
replaced by the IP address of your keystone server.
Alternatively, you can use the python-keystoneclient library to write a
little python example.
** Also affects: python-openstackclient
Importance: Undecided
Status: New
** Changed in: python-openstackclient
Assignee: (unassigned) => Henry Nash (henry-nash)
** Changed in: python-openstackclient
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/1586289
Title:
openstack project list can not list the project which is domain.
Status in OpenStack Identity (keystone):
In Progress
Status in python-openstackclient:
Confirmed
Bug description:
version:mitaka
question:
In project table of keystone database, there are following projects:
+--+--+---+---+-+--+---+---+
| id | name | extra |
description | enabled | domain_id
| parent_id | is_domain |
+--+--+---+---+-+--+---+---+
| 1e424dd1844b4a7d81d5b167f188192d | heat | {}| Owns
users and projects created by heat | 1 | <> |
NULL | 1 |
| 388ba5efe7c24cd6b4762b9c6f60a5d5 | magnum | {}| Owns
users and projects created by magnum | 1 | <> |
NULL | 1 |
| 4d6e4e79ea1f4ec392475308e11a895d | admin| {}|
Bootstrap project for initializing the cloud. | 1 | default
| default | 0 |
| 749e9ebce1d24c4aa5463382c6d2c526 | demo | {}|
| 1 | default |
default | 0 |
| 9314197e00bc43e197995681cff786cc | alt_demo | {}|
| 1 | default |
default | 0 |
| <> | <> | {}|
| 0 | <> |
NULL | 1 |
| b79ace1760194778916e18cfb053a6d1 | service | {}|
| 1 | default |
default | 0 |
| cf443a4f9b9749c9a172915ce48d7989 | project_a| {}|
| 1 | default |
default | 0 |
| d076df0e55d24881a61325cd6bb7f6f4 | project_b| {}|
| 1 | default |
default | 0 |
| d90353b3872749719e2a5c9343f9acce | invisible_to_admin | {}|
| 1 | default |
default | 0 |
| default | Default | {}| The
default domain| 1 | <>
| NULL | 1 |
+--+--+---+---+-+--+---+---+
But when I execute openstack project list, I got following result:
+--++
| ID | Name |
+--++
| 4d6e4e79ea1f4ec392475308e11a895d | admin |
| 749e9ebce1d24c4aa5463382c6d2c526 | demo |
| 9314197e00bc43e197995681cff786cc | alt_demo |
| b79ace1760194778916e18cfb053a6d1 | service|
| cf443a4f9b9749c9a172915ce48d7989 | project_a |
| d076df0e55d24881a61325cd6bb7f6f4 | project_b |
| d90353b3872749719e2a5c9343f9acce | invisible_to_admin |
+--++
The project which is domain can not list, such as heat, magnum,
<>, Default.
To manage notifications about this b
[Yahoo-eng-team] [Bug 1583948] Re: getting whole user-roles in domain or project in V3
This is not a bug, it is working as designed. The list grants API only lists explicit grants. If you want to see "effective" grants, you should use he List Assignments API. ** 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/1583948 Title: getting whole user-roles in domain or project in V3 Status in OpenStack Identity (keystone): Invalid Bug description: If one user joins a group and the group has the domain roles, now, we could not get the whole user-roles from the domain, but the user should have the group-domain roles.（the user belongs to the domain.） Eg. Group1 has role1 in domain1, and the user from domain1 joins the Group1, in fact, in V3, the user should has role1, but actually now, we cannot get roles from /v3/domains/domain1/users/user/roles. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1583948/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1569814] [NEW] Incorrect deprecation warning for IdentityDriverV8
Public bug reported: Commit ad7a7bd6ee36a7af61f88d98038d83aba25a9743 (https://review.openstack.org/#/c/296140/) moved driver interfaces for core Identity into their own module (base.py in the backend directory). For compatibility it included a class definition of IdentityDriverV8 in the original location (core.py), with a deprecation warning. @versionutils.deprecated( versionutils.deprecated.MITAKA, what='keystone.identity.IdentityDriverV8', in_favor_of='keystone.identity.backends.base.IdentityDriverV8', remove_in=+1) class IdentityDriverV8(identity_interface.IdentityDriverV8): pass There appear to be two things wrong with this: 1) I don't believe this merged for Mitaka. Hence we can't retrospectively start the deprecation in Mitaka 2) I thought we were committing to 2 cycles for deprecation in general. Hence I think this should be NEWTON + 2. ** 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/1569814 Title: Incorrect deprecation warning for IdentityDriverV8 Status in OpenStack Identity (keystone): New Bug description: Commit ad7a7bd6ee36a7af61f88d98038d83aba25a9743 (https://review.openstack.org/#/c/296140/) moved driver interfaces for core Identity into their own module (base.py in the backend directory). For compatibility it included a class definition of IdentityDriverV8 in the original location (core.py), with a deprecation warning. @versionutils.deprecated( versionutils.deprecated.MITAKA, what='keystone.identity.IdentityDriverV8', in_favor_of='keystone.identity.backends.base.IdentityDriverV8', remove_in=+1) class IdentityDriverV8(identity_interface.IdentityDriverV8): pass There appear to be two things wrong with this: 1) I don't believe this merged for Mitaka. Hence we can't retrospectively start the deprecation in Mitaka 2) I thought we were committing to 2 cycles for deprecation in general. Hence I think this should be NEWTON + 2. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1569814/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1558350] Re: No rest api for /v3/projects/{projectId}/users
So the v2 API is really a hang over from when creating a user with a
default project automatically granted you a role on that project,
leading to the concept of "user for a project". In v3 such an automatic
assignment does not occur, and in v3 we focus much more on the direct
assignments (i.e. user/group on project/domain).
In v3 we have the (much more comprehensive) GET /role_assignments API,
which allows you to list assignments filtered by various attributes, for
example:
GET /role_assignments?scope.project_id=MyProject
will list you all the assignments on a given project. Further, if you
want to take into account group and inherited assignments, you can issue
an API like:
GET /role_assignments?scope.project_id=MyProject?effective
See the Identity v3 API for more info: https://github.com/openstack
/keystone-specs/blob/master/api/v3/identity-api-v3.rst
** Changed in: keystone
Status: New => Won't Fix
** Changed in: keystone
Status: Won't Fix => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1558350
Title:
No rest api for /v3/projects/{projectId}/users
Status in OpenStack Identity (keystone):
Invalid
Bug description:
I want to list users in a specified project using admin token, however
I find there is no rest api for /v3/projects/{projectId}/users, it is
really useful. I notice there is /v2/tenants/{tenantId}/users for this
purpose. Is there any reason that it is removed from v3? Thanks!
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1558350/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1546039] [NEW] If one trustor role is removed, the trust cannot be used
Public bug reported: If a trust is created with a list of roles, when the trust is used by the trustee to obtain a token, we first make sure that the trustor still has all the delegated roles. However, the way the code is written, if any have been removed, we immediately fail the token creation, rather than, instead, grant the token with the remaining roles. The current exception comment suggests that this was not our intention. ** 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/1546039 Title: If one trustor role is removed, the trust cannot be used Status in OpenStack Identity (keystone): New Bug description: If a trust is created with a list of roles, when the trust is used by the trustee to obtain a token, we first make sure that the trustor still has all the delegated roles. However, the way the code is written, if any have been removed, we immediately fail the token creation, rather than, instead, grant the token with the remaining roles. The current exception comment suggests that this was not our intention. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1546039/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1539140] [NEW] Current logging in Keystone does not enable operators to determine what is happening
Public bug reported: Our current logging is meant to provide different levels so that operators can enable a suitable level (e.g. INFO) without going full DEBUG (which operators consider potentially risky). INFO doesn't, however, give you anything consistent. ** 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/1539140 Title: Current logging in Keystone does not enable operators to determine what is happening Status in OpenStack Identity (keystone): New Bug description: Our current logging is meant to provide different levels so that operators can enable a suitable level (e.g. INFO) without going full DEBUG (which operators consider potentially risky). INFO doesn't, however, give you anything consistent. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1539140/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1535878] [NEW] A role with a role on a project should be able to issue a GET /project call
Public bug reported: Currently, we require project admin or "higher" in order to issue a GET /project call. This seems overly restrictive, since if you have a role on a project, I would think you should be able to issue GET /project. Further, there are cases (such as other projects wanting work work au quotas) where being able to get the info on a project (such as it's parent) that are important. ** 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/1535878 Title: A role with a role on a project should be able to issue a GET /project call Status in OpenStack Identity (keystone): New Bug description: Currently, we require project admin or "higher" in order to issue a GET /project call. This seems overly restrictive, since if you have a role on a project, I would think you should be able to issue GET /project. Further, there are cases (such as other projects wanting work work au quotas) where being able to get the info on a project (such as it's parent) that are important. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1535878/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1533346] [NEW] federation create_mapping signature and V9 wrapper incorrect
Public bug reported: The original abstract signature for the create_mapping() driver method was wrong in the federation manager in Liberty. This was then inadvertently copied to the V9wrapper when we created the V9 driver in Mitaka. This would cause V8 federation drivers to fail with Mitaka. The legacy testing did not cover all the CRUD tests, which is why this was not discovered when the V9 driver was created. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) Status: In Progress ** Changed in: keystone Importance: Undecided => High ** Changed in: keystone Assignee: (unassigned) => Henry Nash (henry-nash) -- 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/1533346 Title: federation create_mapping signature and V9 wrapper incorrect Status in OpenStack Identity (keystone): In Progress Bug description: The original abstract signature for the create_mapping() driver method was wrong in the federation manager in Liberty. This was then inadvertently copied to the V9wrapper when we created the V9 driver in Mitaka. This would cause V8 federation drivers to fail with Mitaka. The legacy testing did not cover all the CRUD tests, which is why this was not discovered when the V9 driver was created. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1533346/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1443912] Re: Non-translation-friendly formatting of msg string
Due to the fact that we use the msg both for a log and an exception, I
think this code is OK
** 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/1443912
Title:
Non-translation-friendly formatting of msg string
Status in OpenStack Identity (keystone):
Invalid
Bug description:
The token controller doesn't adhere to the guidance for string
translations, instead it pre-formats the substitutions into the msg
before raising an exception.
msg = _('User %(u_id)s is unauthorized for tenant %(t_id)s')
msg = msg % {'u_id': user_id, 't_id': tenant_id}
LOG.warning(msg)
raise exception.Unauthorized(msg)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1443912/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1522433] [NEW] API Version info incorrect for Liberty
Public bug reported:
Our API allows you to query keystone for the version that is supports
(e.g. V2 and v3), as well as the minor version we support (e.g. 3.4) as
well as other status of the API. Looks like this was not updated for
the Liberty release:
versions['v3'] = {
'id': 'v3.4',
'status': 'stable',
'updated': '2015-03-30T00:00:00Z',
'links': [
{
'rel': 'self',
'href': self._get_identity_url(context, 'v3'),
}
],
'media-types': [
{
'base': 'application/json',
'type': MEDIA_TYPE_JSON % 'v3'
}
]
}
The above is from version/controller.py.
Liberty supports version 3.5 of the API, and the date needs to be
updated.
** 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/1522433
Title:
API Version info incorrect for Liberty
Status in OpenStack Identity (keystone):
New
Bug description:
Our API allows you to query keystone for the version that is supports
(e.g. V2 and v3), as well as the minor version we support (e.g. 3.4)
as well as other status of the API. Looks like this was not updated
for the Liberty release:
versions['v3'] = {
'id': 'v3.4',
'status': 'stable',
'updated': '2015-03-30T00:00:00Z',
'links': [
{
'rel': 'self',
'href': self._get_identity_url(context, 'v3'),
}
],
'media-types': [
{
'base': 'application/json',
'type': MEDIA_TYPE_JSON % 'v3'
}
]
}
The above is from version/controller.py.
Liberty supports version 3.5 of the API, and the date needs to be
updated.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1522433/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1517038] [NEW] API-based Domain config method could temporarily show partial update
Public bug reported: When using the API-based domain config method, the options are not updated atomically. The result is that for a "cache update period", someone else reading the options (i.e. the processing of a user/group API call in another keystone process) might see a partial update. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Assignee: (unassigned) => Henry Nash (henry-nash) ** Changed in: keystone 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/1517038 Title: API-based Domain config method could temporarily show partial update Status in OpenStack Identity (keystone): New Bug description: When using the API-based domain config method, the options are not updated atomically. The result is that for a "cache update period", someone else reading the options (i.e. the processing of a user/group API call in another keystone process) might see a partial update. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1517038/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1517037] [NEW] API-based Domain specific config does not check for type of option
Public bug reported: When using the API method for specifying domain specific options for config values, we don't check that the type of option specified via the API matches the underlying config option type. This could lead to strange results which would be hard for an operator to debug in the field. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Assignee: (unassigned) => Henry Nash (henry-nash) ** Changed in: keystone 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/1517037 Title: API-based Domain specific config does not check for type of option Status in OpenStack Identity (keystone): New Bug description: When using the API method for specifying domain specific options for config values, we don't check that the type of option specified via the API matches the underlying config option type. This could lead to strange results which would be hard for an operator to debug in the field. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1517037/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1516226] [NEW] Keystone V2 User API can access users outside of the default domain
Public bug reported: The Keystone V2 API is not mean to be able to "see" any user, groups or projects outside of the default domain. APIs that list these entities are careful to filter out any that are in non-default-domains. However, if you know your entity ID we don't prevent you from doing direct lookup - i.e.. Get /users/ will work via the V2 API even if the user is out side of the default domain. The same is true for projects. Since the V2 API does not have the concept of groups, there is no issue in that case. ** 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/1516226 Title: Keystone V2 User API can access users outside of the default domain Status in OpenStack Identity (keystone): New Bug description: The Keystone V2 API is not mean to be able to "see" any user, groups or projects outside of the default domain. APIs that list these entities are careful to filter out any that are in non-default- domains. However, if you know your entity ID we don't prevent you from doing direct lookup - i.e.. Get /users/ will work via the V2 API even if the user is out side of the default domain. The same is true for projects. Since the V2 API does not have the concept of groups, there is no issue in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1516226/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1484577] Re: OS-INHERIT does not seem to work for users but works for groups
*** This bug is a duplicate of bug 1403539 *** https://bugs.launchpad.net/bugs/1403539 I'm closing this defect, since it is essentially a duplicate of https://bugs.launchpad.net/keystone/+bug/1403539. Please re-open if you think there is a distinct defect here. ** This bug has been marked a duplicate of bug 1403539 Can't create both inherited and direct role assignment on same entities -- 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/1484577 Title: OS-INHERIT does not seem to work for users but works for groups Status in OpenStack Identity (keystone): Triaged Bug description: Using Kilo, I'm following thehttp://specs.openstack.org/openstack /keystone-specs/api/v3/identity-api-v3-os-inherit-ext.html#what-s-new- in-version-1-1 instructions to experiment with role inheritances on projects of a domain. (not dealing with subprojects just yet). I'm having some problem getting OS-INHERIT to work when the target of the assignment is a user. It works if the target is a group. I'm able to PUT a project role inheritance record but not get it back: PUT: /v3/OS-INHERIT/ domains/288b1c4d3f7b43a4b8708016d9ae3ec5/ users/257cc461fde84f8aac1af1b42a7314f2/ roles/daa86839ba154426ad34a95975d2d188/inherited_to_projects (side note: I noticed though that it validates domain, roles, but not user. The PUT succeeds if I put an invalid user.) HEAD on the same path above returns 404. Also, this: GET: /v3/OS-INHERIT/ domains/288b1c4d3f7b43a4b8708016d9ae3ec5/ users/257cc461fde84f8aac1af1b42a7314f2/ roles/inherited_to_projects returns 200, but an empty list of roles. So somehow, the PUT doesn't stick, I'm not sure why. Consequently, I'm also not able to get a project token with expected roles from the domain etc. Interestingly, this works with groups. In other words, if I do a: PUT: /v3/OS-INHERIT/ domains/d groups/g/ roles/x then, a user from that group g can get a project scoped token with role x in any project of domain d. It doesn't seem to be working when using the inherited grant on users directly? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1484577/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1502157] [NEW] Updating a project's domain_id can create an illegal project hierarchy
Public bug reported: We introduced hierarchical projects in Kilo. The design (both then and now) was that a project hierarchy existed in a single domain (i.e. all the projects in the hierarchy were owned by the same domain). We also still support (although disabled by default) the ability to change the domain_id of a user, group or project. This is being marked as deprecated in Mitaka. The problem arrises if a cloud deployer changes the config to allow mutable domain_ids, creates a hierarchy of projects and then changes the domain of a project in the middle of the hierarchy. The hierarchy is now not all owned by the same domain. This ability to change a project that has children or is not a top level project is being removed in Mitaka (we should never have allowed it) - but the fact remains that (however unlikely) someone might have done this in Kilo or Liberty. The question is what to do about it? About the least bad solution I can think of would be to do both: 1) Backport the restriction to stop projects having their domain_id change unless they are a top level project with no children to Liberty (and maybe Kilo). We can't back port the deprecation, or course. 2) Add migration code in Mitaka that spotted a "split hierarchy" and really split the hierarchy (i.e. the two part of the project tree would hang off their respective domains). To really do that right, we'd have to duplicate any inherited role assignments. ** 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/1502157 Title: Updating a project's domain_id can create an illegal project hierarchy Status in Keystone: New Bug description: We introduced hierarchical projects in Kilo. The design (both then and now) was that a project hierarchy existed in a single domain (i.e. all the projects in the hierarchy were owned by the same domain). We also still support (although disabled by default) the ability to change the domain_id of a user, group or project. This is being marked as deprecated in Mitaka. The problem arrises if a cloud deployer changes the config to allow mutable domain_ids, creates a hierarchy of projects and then changes the domain of a project in the middle of the hierarchy. The hierarchy is now not all owned by the same domain. This ability to change a project that has children or is not a top level project is being removed in Mitaka (we should never have allowed it) - but the fact remains that (however unlikely) someone might have done this in Kilo or Liberty. The question is what to do about it? About the least bad solution I can think of would be to do both: 1) Backport the restriction to stop projects having their domain_id change unless they are a top level project with no children to Liberty (and maybe Kilo). We can't back port the deprecation, or course. 2) Add migration code in Mitaka that spotted a "split hierarchy" and really split the hierarchy (i.e. the two part of the project tree would hang off their respective domains). To really do that right, we'd have to duplicate any inherited role assignments. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1502157/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1493126] Re: openstack group create fails while using admin token
I do not consider this a bug. We state that you must either explicitly
supply the domain_id of a group in the entity passed to the create call
OR use a domain scoped token. Since the ADMIN token is not a domain
scoped token, you must provide it in the entity itself (which, to be
honest, should be the recommended way of doing it anyway).
** 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/1493126
Title:
openstack group create fails while using admin token
Status in Keystone:
Invalid
Bug description:
While using --os-token=ADMIN_TOKEN rather then admin user credentials
fails with error message:
$ openstack --os-token= group create "qwerty"
ERROR: openstack The request you have made requires authentication. (Disable
debug mode to suppress these details.) (HTTP 401) (Request-ID: req-8b45e<...>)
OS_USERNAME and OS_PASSWORD are set to ""
Keystone log contains:
2015-09-07 19:30:50.514850 14499 DEBUG keystone.middleware.core [-] RBAC:
auth_context: {} process_request
/opt/stack/keystone/keystone/middleware/core.py:209
2015-09-07 19:30:50.533697 14499 INFO keystone.common.wsgi [-] POST
http://172.16.51.28:5000/v3/groups
2015-09-07 19:30:50.536504 14499 WARNING keystone.common.controller [-] RBAC:
Bypassing authorization
2015-09-07 19:30:50.539266 14499 WARNING keystone.common.utils [-] Couldn't
find the auth context.
2015-09-07 19:30:50.547398 14499 WARNING keystone.common.wsgi [-]
Authorization failed. The request you have made requires authentication.
(Disable debug mode to suppress these details.) (Disable debug mode to suppress
these details.) from
Using admin credentials works fine.
---
Investigation gave me that the root cause of this is that during group
creation [0] the token information is being extracted from context [1] which is
{empty} for request authenticated using ADMIN_TOKEN [2]
[0]
https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L300
[1]
https://github.com/openstack/keystone/blob/master/keystone/common/utils.py#L523-L525
[2]
https://github.com/openstack/keystone/blob/master/keystone/middleware/core.py#L72
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1493126/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1482330] [NEW] Creating a user/group/project without a domain should raise an exception
Public bug reported: According to the API spec, you must supply a domain for a user, group or project on create. You can do this either by specifying it explicitly in the object or by using a domain scoped token. Although the spec doesn't say this explicitly, one would expect an exception to be raised if you don't do either the these (e.g. try using a project scoped token). However, due to a long fixed bug (1283539) in a heat tempest, we actually fall back and try and use the default domain (which may still fail of course if you don't have a role on the default domain). This fall back is neither in the spec nor is it sensible in the long run. We should raise a ValidationError in the situation when no domain is specified. The only one concern I have is whether someone might have discovered this fall back in the fieldand so there is an argument as to whether we should add deprecation warning if we detect this situation for a cycle? ** Affects: keystone Importance: Undecided Assignee: Henry Nash (henry-nash) Status: In Progress ** Summary changed: - Creating a user/group without a domain should raise an exception + Creating a user/group/project without a domain should raise an exception ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1482330 Title: Creating a user/group/project without a domain should raise an exception Status in Keystone: In Progress Bug description: According to the API spec, you must supply a domain for a user, group or project on create. You can do this either by specifying it explicitly in the object or by using a domain scoped token. Although the spec doesn't say this explicitly, one would expect an exception to be raised if you don't do either the these (e.g. try using a project scoped token). However, due to a long fixed bug (1283539) in a heat tempest, we actually fall back and try and use the default domain (which may still fail of course if you don't have a role on the default domain). This fall back is neither in the spec nor is it sensible in the long run. We should raise a ValidationError in the situation when no domain is specified. The only one concern I have is whether someone might have discovered this fall back in the fieldand so there is an argument as to whether we should add deprecation warning if we detect this situation for a cycle? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1482330/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1481145] Re: Keystone could create domain when Identity driver is LDAP and Resource driver is SQL
So this is by design.Iif you are using LDAP for Identity and want to use
multiple domain, then you need to enable domain specific drivers in
Identity. This is done using the identity config
domain_specific_drivers_enabled option. However, I'd recommend you read
the keystone confirguration.rst for a description of the methods of
specifying how each domain is backed by LDAP.
** 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/1481145
Title:
Keystone could create domain when Identity driver is LDAP and Resource
driver is SQL
Status in Keystone:
Invalid
Bug description:
Recently , I found a problem about creating domain when I set my
Identity driver to LDAP , and Resource driver to SQL(since I just
found resource driver for LDAP is still working on, could do more
actions on Domain resource).
I could not create a domain when identity driver is LDAP , and
resource driver is SQL, but this use case could be done when identity
driver is SQL and resource driver is SQL.
I wonder if it is a design just like that , if so , could you help me
to some guide docs about this ?
Since checked with source code , I found it may be lead by code :
path : ./keystone/identity/core.py
def is_domain_aware(self):
Indicates if Driver supports domains.
return True
since SQL backend driver inherited the Driver , and
is_domain_aware() is true , but LDAP backend driver
is_domain_driver() is False .
So , there is one explain in ./keystone/identity/core.py : this
method is_domain_driver() is used to Indicates if Driver supports
domains. , and I checked with ./keystone/identity/backends/ldap.py
,
class UserApi(common_ldap.EnabledEmuMixIn, common_ldap.BaseLdap):
DEFAULT_OU = 'ou=Users'
DEFAULT_STRUCTURAL_CLASSES = ['person']
DEFAULT_ID_ATTR = 'cn'
DEFAULT_OBJECTCLASS = 'inetOrgPerson'
NotFound = exception.UserNotFound
options_name = 'user'
attribute_options_names = {'password': 'pass',
'email': 'mail',
'name': 'name',
'enabled': 'enabled',
'default_project_id': 'default_project_id'}
there is no domain_id section , so that is why is_domain_aware() ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1481145/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1476964] Re: keystone/backends.py two lines should be deleted
I don't think you want to do that for two reasons: 1) It is confusing 2) The keys in DRIVER dict are used by code to actually call the managers, so you have just broken all the identity and assignment calls. ** 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/1476964 Title: keystone/backends.py two lines should be deleted Status in Keystone: Invalid Bug description: keystone/backends.py 39 _IDENTITY_API = identity.Manager() 40 _ASSIGNMENT_API = assignment.Manager() 41 42 DRIVERS = dict( 43 assignment_api=_ASSIGNMENT_API, 44 catalog_api=catalog.Manager(), 45 credential_api=credential.Manager(), 46 domain_config_api=resource.DomainConfigManager(), 47 endpoint_filter_api=endpoint_filter.Manager(), 48 endpoint_policy_api=endpoint_policy.Manager(), 49 federation_api=federation.Manager(), 50 id_generator_api=identity.generator.Manager(), 51 id_mapping_api=identity.MappingManager(), 52 identity_api=_IDENTITY_API, There is no need to name two const _IDENTITY_API and _ASSIGNMENT_API, should change into 42 DRIVERS = dict( 43 assignment_api= identity.Manager(), 44 catalog_api=catalog.Manager(), 45 credential_api=credential.Manager(), 46 domain_config_api=resource.DomainConfigManager(), 47 endpoint_filter_api=endpoint_filter.Manager(), 48 endpoint_policy_api=endpoint_policy.Manager(), 49 federation_api=federation.Manager(), 50 id_generator_api=identity.generator.Manager(), 51 id_mapping_api=identity.MappingManager(), 52 identity_api=assignment.Manager(), To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1476964/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466772] [NEW] File based domain config checks contain unused code
Public bug reported:
The domain config processing handles the case when the config settings
are coming from a domain-specific config file or via the API separately.
However, there is some redundant code in the check for multiple sql
drivers for the file based case. which is a hang over from when this
code path tried to handle both cases. This can now be removed.
Example:
if not config_file:
config_file = _('Database at /domains/%s/config') % domain_id
raise exception.MultipleSQLDriversInConfig(source=config_file)
** Affects: keystone
Importance: Low
Assignee: Henry Nash (henry-nash)
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/1466772
Title:
File based domain config checks contain unused code
Status in OpenStack Identity (Keystone):
New
Bug description:
The domain config processing handles the case when the config settings
are coming from a domain-specific config file or via the API
separately. However, there is some redundant code in the check for
multiple sql drivers for the file based case. which is a hang over
from when this code path tried to handle both cases. This can now be
removed. Example:
if not config_file:
config_file = _('Database at /domains/%s/config') % domain_id
raise exception.MultipleSQLDriversInConfig(source=config_file)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1466772/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1443912] [NEW] Non-translation-friendly formatting of msg string
Public bug reported:
The token controller doesn't adhere to the guidance for string
translations, instead it pre-formats the substitutions into the msg
before raising an exception.
msg = _('User %(u_id)s is unauthorized for tenant %(t_id)s')
msg = msg % {'u_id': user_id, 't_id': tenant_id}
LOG.warning(msg)
raise exception.Unauthorized(msg)
** Affects: keystone
Importance: Low
Assignee: Henry Nash (henry-nash)
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/1443912
Title:
Non-translation-friendly formatting of msg string
Status in OpenStack Identity (Keystone):
New
Bug description:
The token controller doesn't adhere to the guidance for string
translations, instead it pre-formats the substitutions into the msg
before raising an exception.
msg = _('User %(u_id)s is unauthorized for tenant %(t_id)s')
msg = msg % {'u_id': user_id, 't_id': tenant_id}
LOG.warning(msg)
raise exception.Unauthorized(msg)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1443912/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440107] [NEW] Clearing up project assignments makes assumptions that domain_id != project_id
Public bug reported: The method delete_project_assignments() in the assignment backends removes all assignments for a project - although the code fails to set the type of assignment, and just uses target_id. This is nearly always going to be fine, although technically one should also specify the type of the assignment in the delete (e.g. USER_PROJECT or GROUP_PROJECT). ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) 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/1440107 Title: Clearing up project assignments makes assumptions that domain_id != project_id Status in OpenStack Identity (Keystone): New Bug description: The method delete_project_assignments() in the assignment backends removes all assignments for a project - although the code fails to set the type of assignment, and just uses target_id. This is nearly always going to be fine, although technically one should also specify the type of the assignment in the delete (e.g. USER_PROJECT or GROUP_PROJECT). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1440107/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440135] [NEW] Cleaning up user/group assignments makes incorrect assumption that user_id != group_id
Public bug reported: The methods delete_user_assignments() and delete_group_assignments() in the assignment backends removes all assignments for a user/group - although the code fails to set the type of assignment, and just uses actor_id. This is nearly always going to be fine, although technically one should also specify the type of the assignment in the delete (e.g. USER_PROJECT/USER_DOMAIN and USER_PROJECT/GROUP_PROJECT). ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) 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/1440135 Title: Cleaning up user/group assignments makes incorrect assumption that user_id != group_id Status in OpenStack Identity (Keystone): New Bug description: The methods delete_user_assignments() and delete_group_assignments() in the assignment backends removes all assignments for a user/group - although the code fails to set the type of assignment, and just uses actor_id. This is nearly always going to be fine, although technically one should also specify the type of the assignment in the delete (e.g. USER_PROJECT/USER_DOMAIN and USER_PROJECT/GROUP_PROJECT). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1440135/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1438529] [NEW] Assignment manager uses .driver. unnecessarily in many places
Public bug reported: There are many cases in the assignment manager where it uses .driver. to call unique methods in the driver - which is not required, since we already have these methods patched into the class. ** Affects: keystone Importance: Wishlist Assignee: Henry Nash (henry-nash) Status: New ** Summary changed: - Identity manager uses .driver. unnecessarily in many places + Assignment manager uses .driver. unnecessarily in many places ** Description changed: - There are many cases in the Identity manager where it uses .driver. to + There are many cases in the assignment manager where it uses .driver. to call unique methods in the driver - which is not required, since we already have these methods patched into the class. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1438529 Title: Assignment manager uses .driver. unnecessarily in many places Status in OpenStack Identity (Keystone): New Bug description: There are many cases in the assignment manager where it uses .driver. to call unique methods in the driver - which is not required, since we already have these methods patched into the class. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1438529/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1438617] [NEW] Domain config management is not thread-safe
Public bug reported: The domain configuration management methods use a set on non-atomic operations to store the values in the database. This means that in multi-threaded configurations, a GET might, for instance, return a partial config if it where being modified by another thread at the same time. Domain configuration management are relatively infrequent operations, but someone, somewhere will fall into this hole. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) 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/1438617 Title: Domain config management is not thread-safe Status in OpenStack Identity (Keystone): New Bug description: The domain configuration management methods use a set on non-atomic operations to store the values in the database. This means that in multi-threaded configurations, a GET might, for instance, return a partial config if it where being modified by another thread at the same time. Domain configuration management are relatively infrequent operations, but someone, somewhere will fall into this hole. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1438617/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1438827] [NEW] Lazy loading of domain configs can lead to issues
Public bug reported: This lazy loading was created to avoid a circular dependancy between identity and assignment. However it has a number of issues: (Extracted from Bug #1410850) First - if someone will call .setup_domain_drivers(...) multiple times(perhaps we should add self.create() in this method or raise exception on second call of this method). Second - .reload_domain_driver don't take in a count ._any_sql attribute. So if domain config will change backend type and it become SQL or become not SQL... we will have a problems. Also, it seems a messy compilation all over the code that is prone to error. ** Affects: keystone Importance: Medium Status: New ** Changed in: keystone Importance: Undecided = Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1438827 Title: Lazy loading of domain configs can lead to issues Status in OpenStack Identity (Keystone): New Bug description: This lazy loading was created to avoid a circular dependancy between identity and assignment. However it has a number of issues: (Extracted from Bug #1410850) First - if someone will call .setup_domain_drivers(...) multiple times(perhaps we should add self.create() in this method or raise exception on second call of this method). Second - .reload_domain_driver don't take in a count ._any_sql attribute. So if domain config will change backend type and it become SQL or become not SQL... we will have a problems. Also, it seems a messy compilation all over the code that is prone to error. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1438827/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1438517] [NEW] Identity driver clean-up methods have confusing names
Public bug reported: The Identity driver supports a number of clean-up methods for other manages to call (either directly or via notifications), such as delete_project_assignments() which will delete all roles related to a project (which, perhaps, is being deleted). Two of these clean-up methods are misnamed: delete_group() delete_user() These should, for clarity, be called: delete_group_assignments() delete_user_assignments() This is already flagged by a TODO comment in the driver class in the identity manager. ** Affects: keystone Importance: Wishlist Assignee: Henry Nash (henry-nash) 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/1438517 Title: Identity driver clean-up methods have confusing names Status in OpenStack Identity (Keystone): New Bug description: The Identity driver supports a number of clean-up methods for other manages to call (either directly or via notifications), such as delete_project_assignments() which will delete all roles related to a project (which, perhaps, is being deleted). Two of these clean-up methods are misnamed: delete_group() delete_user() These should, for clarity, be called: delete_group_assignments() delete_user_assignments() This is already flagged by a TODO comment in the driver class in the identity manager. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1438517/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : 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] [NEW] A number of places where we LOG messages fail to use the _L{X} formatting
Public bug reported:
These should be corrected.
** Affects: keystone
Importance: Low
Assignee: Henry Nash (henry-nash)
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/1435693
Title:
A number of places where we LOG messages fail to use the _L{X}
formatting
Status in OpenStack Identity (Keystone):
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 1435315] Re: get_v3_catalog is in the driver section of catalog/core - it should be in the manger
Ah, no, it is using this to get an override in the case of sql. ** 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/1435315 Title: get_v3_catalog is in the driver section of catalog/core - it should be in the manger Status in OpenStack Identity (Keystone): Invalid Bug description: The Driver section of our manages should only hold abstract methods (or internal methods) - but the get_v3_catalog() method is neither of these, yet is still in the Driver section. It should be moved to the manager. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1435315/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1435310] Re: sql backend get_v3_catalog is never used
Ah, now I get what is going on - it is overriding the default one in the Driver class... ** 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/1435310 Title: sql backend get_v3_catalog is never used Status in OpenStack Identity (Keystone): Invalid Bug description: The v3 catalog is created from the v2 catalog in the catolog manager/driver, and the sql backend get_v3_catalog method is therefore never called - and should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1435310/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1435310] [NEW] sql backend get_v3_catalog is never used
Public bug reported: The v3 catalog is created from the v2 catalog in the catolog manager/driver, and the sql backend get_v3_catalog method is therefore never called - and should be removed. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) 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/1435310 Title: sql backend get_v3_catalog is never used Status in OpenStack Identity (Keystone): New Bug description: The v3 catalog is created from the v2 catalog in the catolog manager/driver, and the sql backend get_v3_catalog method is therefore never called - and should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1435310/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1435312] [NEW] v2 and v3 get catalog pass unused metadata parameter
Public bug reported: Both the v2 and v3 get catalog calls take an optional parameter called 'metadata' - but this is never used. It should be removed. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) 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/1435312 Title: v2 and v3 get catalog pass unused metadata parameter Status in OpenStack Identity (Keystone): New Bug description: Both the v2 and v3 get catalog calls take an optional parameter called 'metadata' - but this is never used. It should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1435312/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1435315] [NEW] get_v3_catalog is in the driver section of catalog/core - it should be in the manger
Public bug reported: The Driver section of our manages should only hold abstract methods (or internal methods) - but the get_v3_catalog() method is neither of these, yet is still in the Driver section. It should be moved to the manager. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) 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/1435315 Title: get_v3_catalog is in the driver section of catalog/core - it should be in the manger Status in OpenStack Identity (Keystone): New Bug description: The Driver section of our manages should only hold abstract methods (or internal methods) - but the get_v3_catalog() method is neither of these, yet is still in the Driver section. It should be moved to the manager. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1435315/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1431015] Re: v3/users or groups calls not working without domain_id
You need to be using a domain scoped token for the keystone to pick up
the domain from the token...it looks like the token you are using is an
unscoped token
** 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/1431015
Title:
v3/users or groups calls not working without domain_id
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
The keystone.common.controller._get_domain_id_for_list_request comment says
the below:
Get the domain_id for a v3 list call.
If we running with multiple domain drivers, then the caller must
specify a domain_id either as a filter or as part of the token scope.
But keystone instead of pulling the domain information from the token
scope (the or in that statement), keystone fails with an HTTP 401 if
you don't explicitly indicate the domain with the domain_id query
parameter, as shown with the following commands:
[root@mysystem ~]# curl -k -i -X GET https://127.0.0.1:5000/v3/groups -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 401 Unauthorized
content-length: 114
vary: X-Auth-Token
server: Apache/2.4.6 (Red Hat) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5
date: Wed, 11 Mar 2015 20:50:31 GMT
content-type: application/json
www-authenticate: Keystone
uri=https://ip9-114-226-167.pok.stglabs.ibm.com:5000;
{error: {message: The request you have made requires
authentication., code: 401, title: Unauthorized}}
[root@mysystem ~]# curl -k -X GET https://127.0.0.1:5000/v3/auth/tokens -H
Accept: application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
-H X-Subject-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7 | python -mjson.tool
{
token: {
...
user: {
domain: {
id: default,
name: Default
},
id:
0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9,
name: root
}
}
}
[root@mysystem ~]# curl -k -i -X GET
https://127.0.0.1:5000/v3/groups?domain_id=default -H Accept:
application/json -H X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7
HTTP/1.1 200 OK
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1431015/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1429723] Re: Column role_id of table assignment should be properly referenced with table role
No, we explicitly drop this constraint in the 062 migration. The reason is that roles are stored in a different backend to the assignment table - and it isn't safe to have FK relationships across backends. ** 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/1429723 Title: Column role_id of table assignment should be properly referenced with table role Status in OpenStack Identity (Keystone): Invalid Bug description: 'role_id' should be referenced with 'id' of 'role' table, but this is not specified in current code, see https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L404 It seems the upgrade script is okay. https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/038_add_assignment_table.py#L39 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1429723/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1429556] [NEW] Identity API for domain-config should define separate resources for group/option
Public bug reported: The API spec for domain-config contains the resource relationship for the full domain-config, however since it is possible to manipulate subsets of the config (e.g. an individual group or option), we should also define a resource relationship for these, which can be referred to by JSON Home. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) Status: In Progress ** Description changed: The API spec for domain-config contains the resource relationship for the full domain-config, however since it is possible to manipulate subsets of the config (e.g. an individual group or option), we should - also define a resource relationship for this, which can be referred to + also define a resource relationship for these, which can be referred to by JSON Home. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1429556 Title: Identity API for domain-config should define separate resources for group/option Status in OpenStack Identity (Keystone): In Progress Bug description: The API spec for domain-config contains the resource relationship for the full domain-config, however since it is possible to manipulate subsets of the config (e.g. an individual group or option), we should also define a resource relationship for these, which can be referred to by JSON Home. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1429556/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1428600] [NEW] Domain Config updates for specific group/option don't honor NotFound
Public bug reported: The manager API for domain-config database updates should raise a DomainConfigNotFound exception if an explicit group or option as been specified in the url (i.e. passed as a parameter to the manager method) and that group/option is not present in the existing config. Currently the code does check that a) the group/option is one we support (i.e. whitelisted or sensitive), and b) the contents of the new config passed contains (and ONLY contains) the specified group or option ...but it doesn't check that the group/option exists in the original config. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) Status: New ** Description changed: The manager API for domain-config database updates should raise a DomainConfigNotFound exception if an explicit group or option as been - specified in the url (i.e. passed as a parameter to the manager method). - Currently the code does check that + specified in the url (i.e. passed as a parameter to the manager method) + and that group/option is not present in the existing config. Currently + the code does check that a) the group/option is one we support (i.e. whitelisted or sensitive), and b) the contents of the new config passed contains (and ONLY contains) the specified group or option ...but it doesn't check that the group/option exists in the original config. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1428600 Title: Domain Config updates for specific group/option don't honor NotFound Status in OpenStack Identity (Keystone): New Bug description: The manager API for domain-config database updates should raise a DomainConfigNotFound exception if an explicit group or option as been specified in the url (i.e. passed as a parameter to the manager method) and that group/option is not present in the existing config. Currently the code does check that a) the group/option is one we support (i.e. whitelisted or sensitive), and b) the contents of the new config passed contains (and ONLY contains) the specified group or option ...but it doesn't check that the group/option exists in the original config. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428600/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1427437] [NEW] LDAP debug logging during unit tests brings us close to causing jenkins to fail our tests
Public bug reported: The Jenkins runs of our unit tests have a cap of 50Mb of log output..if we generate more than that, then it will fail out tests on the assumption that something is wrong. Our full run of our tests brings us perilously close already to this limit - primarily due to LDAP debug logging. We should switch off ldap debug logging for our unit tests. ** Affects: keystone Importance: Critical Assignee: Henry Nash (henry-nash) 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/1427437 Title: LDAP debug logging during unit tests brings us close to causing jenkins to fail our tests Status in OpenStack Identity (Keystone): New Bug description: The Jenkins runs of our unit tests have a cap of 50Mb of log output..if we generate more than that, then it will fail out tests on the assumption that something is wrong. Our full run of our tests brings us perilously close already to this limit - primarily due to LDAP debug logging. We should switch off ldap debug logging for our unit tests. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1427437/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1426448] [NEW] Identity API spec for creating domain-config should be PUT not POST
Public bug reported:
The API for creating a domain specific config incorrectly shows
POST /domains/{domain_id}/config
instead of
PUT /domains/{domain_id}/config
...which is what the code does, since the /config part of the API is not
valid until the config is create.
** Affects: keystone
Importance: High
Assignee: Henry Nash (henry-nash)
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/1426448
Title:
Identity API spec for creating domain-config should be PUT not POST
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
The API for creating a domain specific config incorrectly shows
POST /domains/{domain_id}/config
instead of
PUT /domains/{domain_id}/config
...which is what the code does, since the /config part of the API is
not valid until the config is create.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1426448/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1426310] [NEW] The identity API spec includes examples of the email attribute
Public bug reported: We do not currently support email as a first class attribute, although our API specification includes it in many examples - leading to the impression that we do support it. We should remove email from these examples. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) 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/1426310 Title: The identity API spec includes examples of the email attribute Status in OpenStack Identity (Keystone): New Bug description: We do not currently support email as a first class attribute, although our API specification includes it in many examples - leading to the impression that we do support it. We should remove email from these examples. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1426310/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1424698] [NEW] Backend fIlter testing could be more comprehensive
Public bug reported: The current filter testing for backends covers some of the filtering combinations (such as startswith) . but not all of them. These should be expanded to provide better coverage (especially as filtering is now supported by SQL and Ldap backends). ** Affects: keystone Importance: Undecided Status: New ** Tags: test-improvement ** Tags added: 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/1424698 Title: Backend fIlter testing could be more comprehensive Status in OpenStack Identity (Keystone): New Bug description: The current filter testing for backends covers some of the filtering combinations (such as startswith) . but not all of them. These should be expanded to provide better coverage (especially as filtering is now supported by SQL and Ldap backends). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1424698/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1422994] [NEW] Backend role tests have duplicate test for get_role
Public bug reported: In test_backend.py, the backend role tests have a test for get_role as a stand alone test and the exact same test as part of test_role_crud: https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_backend.py#L249-L252 These tests are being moved to the new backend unit framework - and this duplication should be removed. ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) 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/1422994 Title: Backend role tests have duplicate test for get_role Status in OpenStack Identity (Keystone): In Progress Bug description: In test_backend.py, the backend role tests have a test for get_role as a stand alone test and the exact same test as part of test_role_crud: https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_backend.py#L249-L252 These tests are being moved to the new backend unit framework - and this duplication should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1422994/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1418956] [NEW] Test utilities assume use of assignment api
Public bug reported: Our test fixtures and v3 test utils call the assignment API under the hood to create assignments. This is normally absolutely fine, although for developers looking to replace the assignments engine with their own, such APIs might fail. While a fuller solution would be to allow the disabling of all existing assignments tests, a simple thing we can do to let out-of-tree experimentation to at least use our test fixtures/utils is not to error out if the assignment APIs return NotImplemented. ** Affects: keystone Importance: Wishlist Assignee: Henry Nash (henry-nash) Status: New ** 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/1418956 Title: Test utilities assume use of assignment api Status in OpenStack Identity (Keystone): New Bug description: Our test fixtures and v3 test utils call the assignment API under the hood to create assignments. This is normally absolutely fine, although for developers looking to replace the assignments engine with their own, such APIs might fail. While a fuller solution would be to allow the disabling of all existing assignments tests, a simple thing we can do to let out-of-tree experimentation to at least use our test fixtures/utils is not to error out if the assignment APIs return NotImplemented. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1418956/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1417451] [NEW] SQL User Group entities still have FK to domain
Public bug reported: The SQL User and Group entities store their domain_id. Even though we have tried to cut the linkage between the identity and resource/assignment components - it turns out that the User Group SQL entities still mark domain_id as a foreign key back to the domain table in resource. This stops proper decoupling between our components (and, for instance, makes it harder to handle domain deletion via notification). We should drop the domain_id FK constraint on User Group entities. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) Status: New ** Description changed: The SQL User and Group entities store their domain_id. Even though we have tried to cut the linkage between the identity and resource/assignment components - it turns out that the User Group SQL entities still mark domain_id as a foreign key back to the domain table in resource. This stops proper decoupling between our components (and, - for instance, makes it hard to hand domain deletion via notification). + for instance, makes it harder to handle domain deletion via + notification). We should drop the domain_id FK constraint on User Group entities. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1417451 Title: SQL User Group entities still have FK to domain Status in OpenStack Identity (Keystone): New Bug description: The SQL User and Group entities store their domain_id. Even though we have tried to cut the linkage between the identity and resource/assignment components - it turns out that the User Group SQL entities still mark domain_id as a foreign key back to the domain table in resource. This stops proper decoupling between our components (and, for instance, makes it harder to handle domain deletion via notification). We should drop the domain_id FK constraint on User Group entities. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1417451/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1415959] [NEW] Role cache details are actually using the assignment values
Public bug reported: When we split the role manager into a separate backend inside the assignment component, we also gave the role manager its own cache config values. However, the actual code still uses the assignment cache values. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) 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/1415959 Title: Role cache details are actually using the assignment values Status in OpenStack Identity (Keystone): New Bug description: When we split the role manager into a separate backend inside the assignment component, we also gave the role manager its own cache config values. However, the actual code still uses the assignment cache values. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1415959/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1415268] [NEW] Testing of backend list_role_assignments needs to be improved
Public bug reported: Although we have quite comprehensive testing of the various filter options on list_role_assignment at the controller level, we don;t have these at the backend manager level. This will become crucial since we are pushing the filtering down into the driver level AND will be rewriting many of the other assignment listing methods to simply call list_role_assignments. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) 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/1415268 Title: Testing of backend list_role_assignments needs to be improved Status in OpenStack Identity (Keystone): In Progress Bug description: Although we have quite comprehensive testing of the various filter options on list_role_assignment at the controller level, we don;t have these at the backend manager level. This will become crucial since we are pushing the filtering down into the driver level AND will be rewriting many of the other assignment listing methods to simply call list_role_assignments. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1415268/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1415169] [NEW] We don't make the dependency clear between identity and resource/assignment LDAP
Public bug reported: If we are using LDAP for Resource/Assignment, our code requires that you are using it for Identity. We only hint at this in our code comments, for instance in https://review.openstack.org/#/c/144824/16/keystone/resource/backends/ldap.py where we say: # This is the only deep dependency from resource back # to identity. The assumption is that if you are using # LDAP for resource, you are using it for identity as well. We should make it clear that is a requirement. We should also make sure that this requirement is made clear in configuration.rst ** 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/1415169 Title: We don't make the dependency clear between identity and resource/assignment LDAP Status in OpenStack Identity (Keystone): New Bug description: If we are using LDAP for Resource/Assignment, our code requires that you are using it for Identity. We only hint at this in our code comments, for instance in https://review.openstack.org/#/c/144824/16/keystone/resource/backends/ldap.py where we say: # This is the only deep dependency from resource back # to identity. The assumption is that if you are using # LDAP for resource, you are using it for identity as well. We should make it clear that is a requirement. We should also make sure that this requirement is made clear in configuration.rst To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1415169/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1414909] [NEW] In some tests, calls to role_api still go via assignment_api
Public bug reported: When we recently split role management into its own backend api, there are a few cases (e.g. in test_backend_ldap.py) where we didn't fully switch over to calling role_api directly. For example: self.role_api.get_role.invalidate(self.assignment_api, self.role_member['id']) where we should really be passing self.role_api as opposed to self.assignment_api in as a parameter. ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Importance: Undecided = Low ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1414909 Title: In some tests, calls to role_api still go via assignment_api Status in OpenStack Identity (Keystone): New Bug description: When we recently split role management into its own backend api, there are a few cases (e.g. in test_backend_ldap.py) where we didn't fully switch over to calling role_api directly. For example: self.role_api.get_role.invalidate(self.assignment_api, self.role_member['id']) where we should really be passing self.role_api as opposed to self.assignment_api in as a parameter. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1414909/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1413276] [NEW] Filtering (and limiting) list domains is not tested
Public bug reported: We test the filtering and limiting of lists in test_backend.py - and do this for projects, users and groups: class LimitTests(filtering.FilterTests): ENTITIES = ['user', 'group', 'project'] We don't do this for domain, since this would have problems with LDAP. We should create a special test for this inside one of the LDAP specific multi-domain classes in test_backend_ldap.py. ** Affects: keystone Importance: Low Status: New ** 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/1413276 Title: Filtering (and limiting) list domains is not tested Status in OpenStack Identity (Keystone): New Bug description: We test the filtering and limiting of lists in test_backend.py - and do this for projects, users and groups: class LimitTests(filtering.FilterTests): ENTITIES = ['user', 'group', 'project'] We don't do this for domain, since this would have problems with LDAP. We should create a special test for this inside one of the LDAP specific multi-domain classes in test_backend_ldap.py. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1413276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1412447] [NEW] SQL identity driver does't support backend filtering on membership queries
Public bug reported: The SQL identity driver leaves filtering on list_users_in_group and list_groups_for_user to the controller. This is probably a reasonable assumption - although the LDAP driver now does support at least filtering on list_groups_for_user (this is included in https://review.openstack.org/#/c/147612/). It would be sensible for SQL to at least match what LDAP can do (and avoid having to skip the test related to this in test_backend_sql). ** Affects: keystone Importance: Low Status: New ** Description changed: - The SQL identity driver leaves filter on list_users_in_group and + The SQL identity driver leaves filtering on list_users_in_group and list_groups_for_user to the controller. This is probably a reasonable assumption - although the LDAP driver now does support at least filtering on list_groups_for_user (this is included in https://review.openstack.org/#/c/147612/). It would be sensible for SQL to at least match what LDAP can do (and avoid having to skip the test related to this in test_backend_sql). ** Changed in: keystone Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1412447 Title: SQL identity driver does't support backend filtering on membership queries Status in OpenStack Identity (Keystone): New Bug description: The SQL identity driver leaves filtering on list_users_in_group and list_groups_for_user to the controller. This is probably a reasonable assumption - although the LDAP driver now does support at least filtering on list_groups_for_user (this is included in https://review.openstack.org/#/c/147612/). It would be sensible for SQL to at least match what LDAP can do (and avoid having to skip the test related to this in test_backend_sql). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1412447/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1411478] [NEW] Any attribute that is equal to 'TRUE' or 'FALSE' is treated as boolean by LDAP drivers
Public bug reported:
Our core LDAP driver makes a dangerous assumption that any attribute
that is equal to the string 'TRUE' or 'FALSE' must be a boolean and will
covert the value accordingly. For instance the following test:
def test_hn1(self):
ref = {
'name': 'TRUE',
'domain_id': CONF.identity.default_domain_id}
ref = self.identity_api.create_user(ref)
ref1 = self.identity_api.get_user(ref['id'])
self.assertEqual(ref ,ref1)
will fail (on an LDAP backend) with:
MismatchError: !=:
reference = {'domain_id': 'default', 'enabled': True, 'id':
'd4202d8717104d2bb2ab49fec5e7fe70', 'name': 'TRUE'}
actual= {'domain_id': 'default', 'enabled': True, 'id':
u'd4202d8717104d2bb2ab49fec5e7fe70', 'name': True}
Ouch!
Now that we have a schema for our models, perhaps we should use that to
determine whether something is a boolean or not? e.g. for projects, we
have:
_project_properties = {
'description': validation.nullable(parameter_types.description),
# NOTE(lbragstad): domain_id isn't nullable according to some backends.
# The identity-api should be updated to be consistent with the
# implementation.
'domain_id': parameter_types.id_string,
'enabled': parameter_types.boolean,
'parent_id': validation.nullable(parameter_types.id_string),
'name': {
'type': 'string',
'minLength': 1,
'maxLength': 64
}
}
For some reason the user/group ones don't exist yet, but we can fix
that.
** Affects: keystone
Importance: High
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/1411478
Title:
Any attribute that is equal to 'TRUE' or 'FALSE' is treated as boolean
by LDAP drivers
Status in OpenStack Identity (Keystone):
New
Bug description:
Our core LDAP driver makes a dangerous assumption that any attribute
that is equal to the string 'TRUE' or 'FALSE' must be a boolean and
will covert the value accordingly. For instance the following test:
def test_hn1(self):
ref = {
'name': 'TRUE',
'domain_id': CONF.identity.default_domain_id}
ref = self.identity_api.create_user(ref)
ref1 = self.identity_api.get_user(ref['id'])
self.assertEqual(ref ,ref1)
will fail (on an LDAP backend) with:
MismatchError: !=:
reference = {'domain_id': 'default', 'enabled': True, 'id':
'd4202d8717104d2bb2ab49fec5e7fe70', 'name': 'TRUE'}
actual= {'domain_id': 'default', 'enabled': True, 'id':
u'd4202d8717104d2bb2ab49fec5e7fe70', 'name': True}
Ouch!
Now that we have a schema for our models, perhaps we should use that
to determine whether something is a boolean or not? e.g. for projects,
we have:
_project_properties = {
'description': validation.nullable(parameter_types.description),
# NOTE(lbragstad): domain_id isn't nullable according to some backends.
# The identity-api should be updated to be consistent with the
# implementation.
'domain_id': parameter_types.id_string,
'enabled': parameter_types.boolean,
'parent_id': validation.nullable(parameter_types.id_string),
'name': {
'type': 'string',
'minLength': 1,
'maxLength': 64
}
}
For some reason the user/group ones don't exist yet, but we can fix
that.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1411478/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1410748] [NEW] Incorrectly named test in backend FilterTests
Public bug reported: test_list_users_filtered() in FilterTests in test_backend is incorrectly named, since it actually tests uses, groups and projects. ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) Status: New ** 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/1410748 Title: Incorrectly named test in backend FilterTests Status in OpenStack Identity (Keystone): New Bug description: test_list_users_filtered() in FilterTests in test_backend is incorrectly named, since it actually tests uses, groups and projects. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1410748/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1410750] [NEW] test_backend has an sql specific test in it
Public bug reported: As part of the filter tests in test_backend.py there is a test called test_filter_sql_injection_attack() which ensures we are not susceptible to sql injection attacks. This test should really be in test_backend_sql.py ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) Status: New ** 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/1410750 Title: test_backend has an sql specific test in it Status in OpenStack Identity (Keystone): New Bug description: As part of the filter tests in test_backend.py there is a test called test_filter_sql_injection_attack() which ensures we are not susceptible to sql injection attacks. This test should really be in test_backend_sql.py To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1410750/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1410029] [NEW] Unnecessary conflict wrapper on assignment driver delete_project() method
Public bug reported: The assignment driver method delete_project is protected by the sql.handle_conflicts wrapper - but that wrapper doesn't do anything for the delete case - and we don't use it for any other delete_entity() method other than project. We should remove this wrapper protection. ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Importance: Undecided = Low ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1410029 Title: Unnecessary conflict wrapper on assignment driver delete_project() method Status in OpenStack Identity (Keystone): New Bug description: The assignment driver method delete_project is protected by the sql.handle_conflicts wrapper - but that wrapper doesn't do anything for the delete case - and we don't use it for any other delete_entity() method other than project. We should remove this wrapper protection. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1410029/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1407540] [NEW] Identity driver has unused pointer to assignment
Public bug reported: During the setup of the identity driver in identity/core, it stores a reference to the assignment_api in the driveralthough this is never used. This should be removed. ** Affects: keystone Importance: Wishlist Assignee: Henry Nash (henry-nash) 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/1407540 Title: Identity driver has unused pointer to assignment Status in OpenStack Identity (Keystone): New Bug description: During the setup of the identity driver in identity/core, it stores a reference to the assignment_api in the driveralthough this is never used. This should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1407540/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1407342] [NEW] Incorrect comment about circular dependency in assignment manager
Public bug reported: The assignment manager has a comment implying that the code in the init() method is working around a circular dependency between identity and assignment. While there is a dependency between assignment and identity in terms of supporting the backward compatibility of the config options for which driver is used, I don't believe there is a circular dependency. The comment should be corrected and be in the init() method itself. ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) Status: New ** Description changed: The assignment manager has a comment implying that the code in the init() method is working around a circular dependency between identity and assignment. While there is a dependency between assignment and identity in terms of supporting the backward compatibility of the config options for which driver is used, I don't believe there is a circular - dependency. The comment should be correct and be in the init() method + dependency. The comment should be corrected and be in the init() method itself. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1407342 Title: Incorrect comment about circular dependency in assignment manager Status in OpenStack Identity (Keystone): New Bug description: The assignment manager has a comment implying that the code in the init() method is working around a circular dependency between identity and assignment. While there is a dependency between assignment and identity in terms of supporting the backward compatibility of the config options for which driver is used, I don't believe there is a circular dependency. The comment should be corrected and be in the init() method itself. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1407342/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1406721] [NEW] RoleNotFound exception not tested for grant APIs
Public bug reported: In general, our unit testing of granting assignments does not test that we throw a RoleNotFound exception if the role_id supplied does not exit. While it might argued that the assignment APIs shouldn't validate this (like we don't validate user/grouo ids), currently the spec (and the code) says that we do. So we should test for this case. This test will be important to ensure functionality does;t change as we split role management into its own backend (and hence the checking of valid role_id is lifted up into the manager) ** Affects: keystone Importance: Wishlist Assignee: Henry Nash (henry-nash) 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/1406721 Title: RoleNotFound exception not tested for grant APIs Status in OpenStack Identity (Keystone): New Bug description: In general, our unit testing of granting assignments does not test that we throw a RoleNotFound exception if the role_id supplied does not exit. While it might argued that the assignment APIs shouldn't validate this (like we don't validate user/grouo ids), currently the spec (and the code) says that we do. So we should test for this case. This test will be important to ensure functionality does;t change as we split role management into its own backend (and hence the checking of valid role_id is lifted up into the manager) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1406721/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1406826] [NEW] master keystone.conf sample is out of sync
Public bug reported: Looks like an update to keystone.common.policy has not been reflected in our keystone.conf sample, leading to this change being included in other commits. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) 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/1406826 Title: master keystone.conf sample is out of sync Status in OpenStack Identity (Keystone): In Progress Bug description: Looks like an update to keystone.common.policy has not been reflected in our keystone.conf sample, leading to this change being included in other commits. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1406826/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1404273] [NEW] ldap assignment driver does not support inherited assignments
Public bug reported: The ldap assignment driver really has no support for inherited role assignments. This was not so bad when we just had domain-project inheritance (since the ldap backend doesn't support domains anyway!), but now that we have project-project inheritance, the ldap backend is significantly deficient. ** 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/1404273 Title: ldap assignment driver does not support inherited assignments Status in OpenStack Identity (Keystone): New Bug description: The ldap assignment driver really has no support for inherited role assignments. This was not so bad when we just had domain-project inheritance (since the ldap backend doesn't support domains anyway!), but now that we have project-project inheritance, the ldap backend is significantly deficient. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1404273/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1404276] [NEW] /auth/projects can include duplicates when using ldap
Public bug reported: The /auth/projects API lists the projects a user has access to (i.e. has any role on). This is sourced from the ldap assignment backed, which (unlike the case for SQL) does not remove duplicate projects from the list. ** 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/1404276 Title: /auth/projects can include duplicates when using ldap Status in OpenStack Identity (Keystone): New Bug description: The /auth/projects API lists the projects a user has access to (i.e. has any role on). This is sourced from the ldap assignment backed, which (unlike the case for SQL) does not remove duplicate projects from the list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1404276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1404276] Re: /auth/projects can include duplicates when using ldap
This was due to a different side effect, not related what was described. ** 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/1404276 Title: /auth/projects can include duplicates when using ldap Status in OpenStack Identity (Keystone): Invalid Bug description: The /auth/projects API lists the projects a user has access to (i.e. has any role on). This is sourced from the ldap assignment backed, which (unlike the case for SQL) does not remove duplicate projects from the list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1404276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1398470] [NEW] sql migration helpers incorrectly inspect for FKs
Public bug reported: Our sql migration tests utilise the migration_helpers to execute such things as adding and removing constraints. In the case of ForeignKeys, the remove helper uses a method like this: def get_constraints_names(table, column_name): fkeys = [fk.name for fk in table.constraints if (column_name in fk.columns and isinstance(fk, sqlalchemy.ForeignKeyConstraint)] return keys The test for column name in fk_colums is unsafe as written, since there are more than just ForeignKeyContraints in table.constraints (and they don't all have a columns attribute). The check should first ensure the item we are looking at IS a ForeignKey, and then check the column. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) ** Changed in: keystone Importance: Undecided = High ** Changed in: keystone Milestone: None = kilo-1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1398470 Title: sql migration helpers incorrectly inspect for FKs Status in OpenStack Identity (Keystone): New Bug description: Our sql migration tests utilise the migration_helpers to execute such things as adding and removing constraints. In the case of ForeignKeys, the remove helper uses a method like this: def get_constraints_names(table, column_name): fkeys = [fk.name for fk in table.constraints if (column_name in fk.columns and isinstance(fk, sqlalchemy.ForeignKeyConstraint)] return keys The test for column name in fk_colums is unsafe as written, since there are more than just ForeignKeyContraints in table.constraints (and they don't all have a columns attribute). The check should first ensure the item we are looking at IS a ForeignKey, and then check the column. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1398470/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1393365] [NEW] cross-manager use of config values for backward compatibility should have deprecation warnings
Public bug reported: There are a few cases where, for backward compatibility, we honor older config values to ensure that installations don't break on upgrade between releases. A good example of this is the 'driver' config setting from when we split up the original identity manager/backend - as well as the config values around the new spit of assignment. We should issue deprecation warnings when the new config values have not been set and the old one still are set (in which case we use the old values). However, the current versionutils.deprecated class doesn't really support the logging of arbitrary objects (it supports just classes and functions). This should be enhanced, and then places where we do provide this backward compatibility for config values should be so marked (The __init__ method in the manager class for resource/core.py and assignment/core.py are good places to start). ** 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/1393365 Title: cross-manager use of config values for backward compatibility should have deprecation warnings Status in OpenStack Identity (Keystone): New Bug description: There are a few cases where, for backward compatibility, we honor older config values to ensure that installations don't break on upgrade between releases. A good example of this is the 'driver' config setting from when we split up the original identity manager/backend - as well as the config values around the new spit of assignment. We should issue deprecation warnings when the new config values have not been set and the old one still are set (in which case we use the old values). However, the current versionutils.deprecated class doesn't really support the logging of arbitrary objects (it supports just classes and functions). This should be enhanced, and then places where we do provide this backward compatibility for config values should be so marked (The __init__ method in the manager class for resource/core.py and assignment/core.py are good places to start). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1393365/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1391682] [NEW] Parameter validation for projects crud should not happen in drivers
Public bug reported: Currently the assignment sql ldap drivers to name cleansing on the project name - this should really be done in the manager to avoid this duplication. ** Affects: keystone Importance: Low Status: New ** Changed in: keystone Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1391682 Title: Parameter validation for projects crud should not happen in drivers Status in OpenStack Identity (Keystone): New Bug description: Currently the assignment sql ldap drivers to name cleansing on the project name - this should really be done in the manager to avoid this duplication. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1391682/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1390640] [NEW] /auth/domains incorrectly includes domains with only user inherited roles
Public bug reported: The /auth/domains API call is meant to return list of domains for which the user could ask for a domain-scoped token - i.e. any domain on which they have a role. However, the code does not differentiate between inherited and non-inherited user roles - and hence might include domains for which the user has no effective role (a domain inherited role ONLY applies to the projects within that domain, not to the domain itself). ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Importance: Undecided = Medium ** Changed in: keystone Importance: Medium = High ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1390640 Title: /auth/domains incorrectly includes domains with only user inherited roles Status in OpenStack Identity (Keystone): New Bug description: The /auth/domains API call is meant to return list of domains for which the user could ask for a domain-scoped token - i.e. any domain on which they have a role. However, the code does not differentiate between inherited and non-inherited user roles - and hence might include domains for which the user has no effective role (a domain inherited role ONLY applies to the projects within that domain, not to the domain itself). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1390640/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1390125] [NEW] Federation tokens can't be handled if assignment backend is LDAP
Public bug reported: The LDAP assignment backend is missing some of the methods used by auth to handle federation tokens, for instance, at least get_roles_for_groups(). ** Affects: keystone Importance: Undecided Status: New ** Description changed: - The LDAP assignment backend is missing some of the method used by auth - to handle federation tokens, for instance get_roles_for_groups(). + The LDAP assignment backend is missing some of the methods used by auth + to handle federation tokens, for instance, at least + get_roles_for_groups(). -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1390125 Title: Federation tokens can't be handled if assignment backend is LDAP Status in OpenStack Identity (Keystone): New Bug description: The LDAP assignment backend is missing some of the methods used by auth to handle federation tokens, for instance, at least get_roles_for_groups(). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1390125/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1389623] [NEW] Duplicate code in test_v3_federation
Public bug reported: In the set set up of sample data, there exists the following: self.TOKEN_SCOPE_DOMAIN_B_FROM_CUSTOMER = self._scope_request( self.tokens['CUSTOMER_ASSERTION'], 'domain', self.domainB['id']) self.TOKEN_SCOPE_DOMAIN_B_FROM_CUSTOMER = self._scope_request( self.tokens['CUSTOMER_ASSERTION'], 'domain', self.domainB['id'] The second statement is a duplicate of the first (formatting aside). ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Importance: Undecided = Low ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1389623 Title: Duplicate code in test_v3_federation Status in OpenStack Identity (Keystone): New Bug description: In the set set up of sample data, there exists the following: self.TOKEN_SCOPE_DOMAIN_B_FROM_CUSTOMER = self._scope_request( self.tokens['CUSTOMER_ASSERTION'], 'domain', self.domainB['id']) self.TOKEN_SCOPE_DOMAIN_B_FROM_CUSTOMER = self._scope_request( self.tokens['CUSTOMER_ASSERTION'], 'domain', self.domainB['id'] The second statement is a duplicate of the first (formatting aside). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1389623/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1389752] [NEW] Project tokens issued from a saml2 auth are missing inherited group roles
Public bug reported: When building the roles in a Keystone token from a saml2 token, we call assignment_api.get_roles_for_groups() to add in any group roles. This appears to ignore the inheritance flag on the assignment - and puts in all group roles whether inherited or not. This means the wrong roles can end up in the resulting Keystone token. The implication is that project scoped tokens would not get any group roles that should be inherited from the domain. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Importance: Undecided = High ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1389752 Title: Project tokens issued from a saml2 auth are missing inherited group roles Status in OpenStack Identity (Keystone): New Bug description: When building the roles in a Keystone token from a saml2 token, we call assignment_api.get_roles_for_groups() to add in any group roles. This appears to ignore the inheritance flag on the assignment - and puts in all group roles whether inherited or not. This means the wrong roles can end up in the resulting Keystone token. The implication is that project scoped tokens would not get any group roles that should be inherited from the domain. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1389752/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1386264] [NEW] /auth/domains does not necessarily return a distinct list
Public bug reported: The underlying code list_domains_for_user() does not (unlike the project equivalent) attempt to filter out duplicates (which would happen if a user had, say, a direct role and a group role, or multiple inherited roles). In all our APIs that return entities based on their effective assignments, we try and make sure we return a distinct list. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Importance: Undecided = Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1386264 Title: /auth/domains does not necessarily return a distinct list Status in OpenStack Identity (Keystone): New Bug description: The underlying code list_domains_for_user() does not (unlike the project equivalent) attempt to filter out duplicates (which would happen if a user had, say, a direct role and a group role, or multiple inherited roles). In all our APIs that return entities based on their effective assignments, we try and make sure we return a distinct list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1386264/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1385643] [NEW] /auth/domains incorrectly includes domains with only inherited roles
Public bug reported: The /auth/domains API call is meant to return list of domains for which the user could ask for a domain-scoped token - i.e. any domain on which they have a role. However, the code does not differentiate between inherited and non-inherited roles - and hence might include domains for which the user has no effective role (a domain inherited role ONLY applies to the projects within that domain, not to the domain itself). ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) Status: New ** Summary changed: - /auth/domains incorrectly includes domain with only inherited roles + /auth/domains incorrectly includes domains with only inherited roles -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1385643 Title: /auth/domains incorrectly includes domains with only inherited roles Status in OpenStack Identity (Keystone): New Bug description: The /auth/domains API call is meant to return list of domains for which the user could ask for a domain-scoped token - i.e. any domain on which they have a role. However, the code does not differentiate between inherited and non-inherited roles - and hence might include domains for which the user has no effective role (a domain inherited role ONLY applies to the projects within that domain, not to the domain itself). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1385643/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1385694] [NEW] /auth/projects fails to include any projects that have inherited group roles
Public bug reported: The /auth/projects API call is meant to return list of projects for which the user could ask for a project-scoped token - i.e. any project on which they have a role. However, the code does look at any roles that a group may have on a domain that are marked as inherited to projects - hence failing to include these projects in the list. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) 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/1385694 Title: /auth/projects fails to include any projects that have inherited group roles Status in OpenStack Identity (Keystone): New Bug description: The /auth/projects API call is meant to return list of projects for which the user could ask for a project-scoped token - i.e. any project on which they have a role. However, the code does look at any roles that a group may have on a domain that are marked as inherited to projects - hence failing to include these projects in the list. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1385694/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1385533] [NEW] Tokens issued from a saml2 auth ignore inheritance of group roles
Public bug reported: When building the roles in a Keystone token from a saml2 token, we call assignment_api.get_roles_for_groups() to add in any group roles. This appears to ignore the inheritance flag on the assignment - and puts in all group roles whether inherited or not. This means the wrong roles can end up in the resulting Keystone token. ** Affects: keystone Importance: High Status: New ** Changed in: keystone Importance: Undecided = High ** Description changed: When building the roles in a Keystone token from a saml2 token, we call assignment_api.get_roles_for_groups() to add in any group roles. This appears to ignore the inheritance flag on the assignment - and puts in - all roles whether inherited or not. This means the wrong roles can end - up in the resulting Keystone token + all group roles whether inherited or not. This means the wrong roles + can end up in the resulting Keystone token. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1385533 Title: Tokens issued from a saml2 auth ignore inheritance of group roles Status in OpenStack Identity (Keystone): New Bug description: When building the roles in a Keystone token from a saml2 token, we call assignment_api.get_roles_for_groups() to add in any group roles. This appears to ignore the inheritance flag on the assignment - and puts in all group roles whether inherited or not. This means the wrong roles can end up in the resulting Keystone token. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1385533/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1197211] Re: v3 Identity tests do not pass if content type is XML
Yep, agreed - I had already told Tahmina to stop work on it. Marking as
Won't Fix.
** Changed in: keystone
Status: Confirmed = Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1197211
Title:
v3 Identity tests do not pass if content type is XML
Status in OpenStack Identity (Keystone):
Won't Fix
Bug description:
The current v3 identity tests only test json. They should test xml as
well, but if you enable this, by creating a test class of:
class TestAuthXML(TestAuthJSON):
content_type = 'xml'
...then tests start failing, e.g.:
ERROR: Call ``PATCH /domains/{domain_id}`` (set enabled=False).
--
Traceback (most recent call last):
File /opt/stack/keystone/tests/test_v3_identity.py, line 109, in
test_disable_domain
self.admin_request(path='/v2.0/tokens', method='POST', body=body)
File /opt/stack/keystone/tests/test_v3.py, line 215, in admin_request
r.result = serializer.from_xml(etree.tostring(r.result))
File /opt/stack/keystone/keystone/common/serializer.py, line 58, in
from_xml
return deserializer(xml)
File /opt/stack/keystone/keystone/common/serializer.py, line 74, in
__call__
return self.walk_element(dom, True)
File /opt/stack/keystone/keystone/common/serializer.py, line 152, in
walk_element
links = child['links']
KeyError: 'links'
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1197211/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1377840] Re: Keystone LDAP delete user - you are not authorized to perform the requested action
Well, with the identity driver set to LDAP there are no user records in Kyetsone - the LDAP driver basically retrieves the user list from the LDAP server directly. So there are no users to remove without touching LDAP. As the error message says - you need to go to your LDAP server to manage user accounts. Please let us know if I have misunderstood the situation you describe. ** 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/1377840 Title: Keystone LDAP delete user - you are not authorized to perform the requested action Status in OpenStack Identity (Keystone): Invalid Bug description: Running an Icehouse setup, keystone connected to LDAP (Microsoft's AD 2003), doing some house cleaning. Keystone user-list gaves a list of users, noticed one old users I'd like to delete. Running below with admin user: # keystone user-delete user1 You are not authorized to perform the requested action, LDAP user delete. (HTTP 403) I didn't setup the LDAP connection my self, it's probably set to ready only. How can I remove this user without touching LDAP user, is it even possible? Suggest returning a more informative notification: Keystone configured with LDAP authentication, please use LDAP to manage users accounts. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1377840/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1375937] [NEW] Downgrade of federation extension can fail due to FKs
Public bug reported: In the 001 migration script of federation, we delete the tables in the wrong order - we should delete the federation_protocol table first, otherwise its FKs to the identity provider cause a problem ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) Status: Triaged ** Tags: juno-rc-potential ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1375937 Title: Downgrade of federation extension can fail due to FKs Status in OpenStack Identity (Keystone): Triaged Bug description: In the 001 migration script of federation, we delete the tables in the wrong order - we should delete the federation_protocol table first, otherwise its FKs to the identity provider cause a problem To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1375937/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1373865] [NEW] Refactor domain usage in test_backend
Public bug reported: The way test_backend uses domains leads to either many of the tests being over overridden in test_backend_ldap, or just skipped (leading to a risk that we are not sufficiently testing certain functionality - see bug 1373113 as an example). There is already a construct for getting the default domain in backend_ldap, but we should use a more flexible scheme for getting test domains so that tests can run whether there is one domain, multiple domains, read-only domains etc. ** Affects: keystone Importance: Wishlist Status: New ** Tags: test-improvement ** Changed in: keystone Importance: Undecided = Wishlist ** Tags added: 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/1373865 Title: Refactor domain usage in test_backend Status in OpenStack Identity (Keystone): New Bug description: The way test_backend uses domains leads to either many of the tests being over overridden in test_backend_ldap, or just skipped (leading to a risk that we are not sufficiently testing certain functionality - see bug 1373113 as an example). There is already a construct for getting the default domain in backend_ldap, but we should use a more flexible scheme for getting test domains so that tests can run whether there is one domain, multiple domains, read-only domains etc. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1373865/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1372287] [NEW] Spelling error in keystone/common/utils.py
Public bug reported: The make_dirs() method in the utils.py file has a spelling error in the doc string comments, namely: Assure the directory exists and optionally set it's ownership and permissions. It's should be its ** Affects: keystone Importance: Low Assignee: TAHMINA AHMED (tahmina-csebuet) Status: In Progress ** Tags: low-hanging-fruit test-improvement ** Changed in: keystone Status: New = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1372287 Title: Spelling error in keystone/common/utils.py Status in OpenStack Identity (Keystone): In Progress Bug description: The make_dirs() method in the utils.py file has a spelling error in the doc string comments, namely: Assure the directory exists and optionally set it's ownership and permissions. It's should be its To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1372287/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1371499] [NEW] Spelling erros in comments in test_backend_ldap.py
Public bug reported: Some minor spelling mistakes could use correcting, namely: # Domain3 has a user created before we switched on # multiple backends, plus one created afterwards - and it's # backend has not changed - so we should fined two. Two mistakes in the same block! ** Affects: keystone Importance: Low Status: New ** Changed in: keystone Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1371499 Title: Spelling erros in comments in test_backend_ldap.py Status in OpenStack Identity (Keystone): New Bug description: Some minor spelling mistakes could use correcting, namely: # Domain3 has a user created before we switched on # multiple backends, plus one created afterwards - and it's # backend has not changed - so we should fined two. Two mistakes in the same block! To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1371499/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1369180] [NEW] keystone logs for unit tests are too verbose
Public bug reported: The current full jenkins run comes close to blowing the 50Mb limit we set for success, meaning that minor changes can tip the logging over this limit and tests fail. Once of the major culprits is that we log every time (for every test) when someone subscribes to a callback notification. This seems overzealous and wasteful of electrons. We should set the default notification log level to INFO in the tests/core.py to suppress this. ** Affects: keystone Importance: Medium Assignee: Henry Nash (henry-nash) Status: New ** Description changed: The current full jenkins run comes close to blowing the 50Mb limit we set for success, meaning that minor changes can tip the logging over - this limit. Once of the major culprits is that we log every time (for - every test) when someone subscribes to a callback notification. These - seems overzealous and wasteful of electrons. + this limit and tests fail. Once of the major culprits is that we log + every time (for every test) when someone subscribes to a callback + notification. This seems overzealous and wasteful of electrons. We should set the default notification log level to INFO in the tests/core.py to suppress this. ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) ** Changed in: keystone Importance: Undecided = Medium ** Changed in: keystone Milestone: None = juno-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1369180 Title: keystone logs for unit tests are too verbose Status in OpenStack Identity (Keystone): New Bug description: The current full jenkins run comes close to blowing the 50Mb limit we set for success, meaning that minor changes can tip the logging over this limit and tests fail. Once of the major culprits is that we log every time (for every test) when someone subscribes to a callback notification. This seems overzealous and wasteful of electrons. We should set the default notification log level to INFO in the tests/core.py to suppress this. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1369180/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1362678] Re: multi-domain has problems with LDAP identity on default domain
no problem...that's good to hear.
** 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/1362678
Title:
multi-domain has problems with LDAP identity on default domain
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
What I try to achieve:
I want to authenticate all users of the default domain against our
company's central LDAP server. This works pretty good.
For Heat I need a user storage that is writable. Our central LDAP
server can not be written from OpenStack. Therefore I configured the
heat domain with SQL identity.
This all works up to the point, when the heat domain admin needs to be
authorized. This authorization request is always processed with the
LDAP identity. I don't know whether the domain is missing here for the
keystone V3 API authorization request or keystone does not route the
request correctly to the SQL identity. To clarify this, I opened this
bug and Steven Hardy encouraged me to do so.
/etc/keystone/keystone.conf:
[identity]
default_domain_id=default
domain_specific_drivers_enabled=true
domain_config_dir=/etc/keystone/domains
driver = keystone.identity.backends.ldap.Identity
[ldap]
url=ldap://ldap2.open-xchange.com:389
suffix=dc=open-xchange,dc=com
etc.
/etc/keystone/domains/keystone.heat.conf:
[identity]
driver = keystone.identity.backends.sql.Identity
[ldap]
/etc/heat/heat.conf:
deferred_auth_method=trusts
trusts_delegated_roles=heat_stack_owner
heat_stack_user_role=heat_stack_user
stack_user_domain=a904d890e0de47dc9f2090c20bb1f45c
stack_domain_admin=heat_domain_admin
stack_domain_admin_password=
openstack --os-token $OS_TOKEN --os-url=http://contorller:5000/v3
--os-identity-api-version=3 domain list
+--+-+-+--+
| ID | Name | Enabled | Description
|
+--+-+-+--+
| a904d890e0de47dc9f2090c20bb1f45c | heat | True | Owns users and
projects created by heat |
| default | Default | True | Owns users and
tenants (i.e. projects) available on Identity API v2. |
+--+-+-+--+
openstack --os-token $OS_TOKEN --os-url=http://controller:5000/v3
--os-identity-api-version=3 user create --password --domain
a904d890e0de47dc9f2090c20bb1f45c --description Manages users and projects
created by heat heat_domain_admin
+-+-+
| Field | Value
|
+-+-+
| description | Manages users and projects created by heat
|
| domain_id | a904d890e0de47dc9f2090c20bb1f45c
|
| enabled | True
|
| id | 38877ca5daed4c9fbbb6c853d3d88e36
|
| links | {u'self':
u'http://controller-test:5000/v3/users/38877ca5daed4c9fbbb6c853d3d88e36'} |
| name | heat_domain_admin
|
+-+-+
openstack --os-token $OS_TOKEN --os-url=http://controller:5000/v3
--os-identity-api-version=3 role add --user
38877ca5daed4c9fbbb6c853d3d88e36 --domain
a904d890e0de47dc9f2090c20bb1f45c admin
Everything set up according to:
http://hardysteven.blogspot.de/2014/04/heat-auth-model-updates-part-1-trusts.html
http://hardysteven.blogspot.de/2014/04/heat-auth-model-updates-part-2-stack.html
I tested this using this example stack: https://github.com/openstack
/heat-templates/blob/master/hot/software-config/example-templates
/example-deploy-sequence.yaml
Then I get the following authentication problem in keystone:
2014-08-28 13:20:40.172 4915 INFO eventlet.wsgi.server [-] 10.20.31.200 - -
[28/Aug/2014 13:20:40] POST /v3/auth/tokens HTTP/1.1 201 12110 0.163805
2014-08-28 13:20:40.326 4915 DEBUG keystone.middleware.core [-] Auth token
not in the request header. Will not build auth context. process_request
[Yahoo-eng-team] [Bug 1363750] [NEW] Fix the minor comments made during revue of endpoint policy
Public bug reported: There were some minor comments made in the version of the endpoint policy extension that was merged: https://review.openstack.org/#/c/115362/15 This should be tidied up. ** 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/1363750 Title: Fix the minor comments made during revue of endpoint policy Status in OpenStack Identity (Keystone): New Bug description: There were some minor comments made in the version of the endpoint policy extension that was merged: https://review.openstack.org/#/c/115362/15 This should be tidied up. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1363750/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1363019] [NEW] test_versions.py is currently breaking pep8 in master
Public bug reported: Somehow a set of bad aligned '}' has got into master in test_versions.py, which is causing every patch to fail. This fixes it. ** Affects: keystone Importance: Critical Assignee: Henry Nash (henry-nash) Status: In Progress ** Changed in: keystone Importance: Undecided = Critical ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) ** Changed in: keystone Milestone: None = juno-3 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1363019 Title: test_versions.py is currently breaking pep8 in master Status in OpenStack Identity (Keystone): In Progress Bug description: Somehow a set of bad aligned '}' has got into master in test_versions.py, which is causing every patch to fail. This fixes it. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1363019/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1363047] [NEW] test_sql_upgrade and live_test not working for non-sqllite DBs
Public bug reported: It appears that our sql upgrade unit tests are broken for DBs that properly support FKs (teardown fails due to FK constraints). I suspect this is because we no longer have the downgrade steps below 034 (since they were squashed). ** Affects: keystone Importance: High Status: New ** Changed in: keystone 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/1363047 Title: test_sql_upgrade and live_test not working for non-sqllite DBs Status in OpenStack Identity (Keystone): New Bug description: It appears that our sql upgrade unit tests are broken for DBs that properly support FKs (teardown fails due to FK constraints). I suspect this is because we no longer have the downgrade steps below 034 (since they were squashed). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1363047/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1362557] [NEW] Performance of list_projects_for_user impacting keystone
Public bug reported: The assignment call list_projects_for_user() is commonly used - not least every time you issue a scoped token. Ina test configuration, this method was consuming 36% of all keystone clock time. This call searches the assignments table (which has one row for every assignment) by actor_id. Although actor_id is part of a composite primary key, when used alone it is like any other non-indexed column. Adding an index for actor ID would significantly improve performance, and since the read of such a table is probably much more frequency than new role assignment being added, this seems like a good trade-off. Such an index would also improve the performance of get role_assignments, when used to get role assignments for a user - which would seem a likely common usage pattern ** 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/1362557 Title: Performance of list_projects_for_user impacting keystone Status in OpenStack Identity (Keystone): New Bug description: The assignment call list_projects_for_user() is commonly used - not least every time you issue a scoped token. Ina test configuration, this method was consuming 36% of all keystone clock time. This call searches the assignments table (which has one row for every assignment) by actor_id. Although actor_id is part of a composite primary key, when used alone it is like any other non-indexed column. Adding an index for actor ID would significantly improve performance, and since the read of such a table is probably much more frequency than new role assignment being added, this seems like a good trade- off. Such an index would also improve the performance of get role_assignments, when used to get role assignments for a user - which would seem a likely common usage pattern To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362557/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1359608] [NEW] Abstract driver signatures for update catalog entities are wrong
Public bug reported: In catalog/core.py, the abstract signature for a number of the update methods are incorrect and don't match what is actually implemented in the driver ** Affects: keystone Importance: Low Assignee: Henry Nash (henry-nash) Status: New ** Changed in: keystone Assignee: (unassigned) = Henry Nash (henry-nash) ** Changed in: keystone Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1359608 Title: Abstract driver signatures for update catalog entities are wrong Status in OpenStack Identity (Keystone): New Bug description: In catalog/core.py, the abstract signature for a number of the update methods are incorrect and don't match what is actually implemented in the driver To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1359608/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1354408] [NEW] Role list in tokens does not match identity-api spec
Public bug reported:
According to the identity-api specification the list or roles in a
scoped token is of the form:
roles: [
{
id: 76e72a,
links: {
self: http://identity:35357/v3/roles/76e72a;
},
name: admin
},
{
id: f4f392,
links: {
self: http://identity:35357/v3/roles/f4f392;
},
name: member
}
],
In fact , the links are not present in our tokens (presumably to keep
token size down?), so a token role list actually looks like:
roles: [
{
id: 76e72a,
name: admin
},
{
id: f4f392,
name: member
}
],
I am presuming we should fix the documentation to match?
** 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/1354408
Title:
Role list in tokens does not match identity-api spec
Status in OpenStack Identity (Keystone):
New
Bug description:
According to the identity-api specification the list or roles in a
scoped token is of the form:
roles: [
{
id: 76e72a,
links: {
self: http://identity:35357/v3/roles/76e72a;
},
name: admin
},
{
id: f4f392,
links: {
self: http://identity:35357/v3/roles/f4f392;
},
name: member
}
],
In fact , the links are not present in our tokens (presumably to keep
token size down?), so a token role list actually looks like:
roles: [
{
id: 76e72a,
name: admin
},
{
id: f4f392,
name: member
}
],
I am presuming we should fix the documentation to match?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1354408/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1354417] [NEW] new_role_ref() in unit tests adds unused attributes
Public bug reported: new_role_ref() simple calls new_ref() which adds creates an entity with 'id', 'name', 'description' and 'enabled'. Roles should only have 'id' and 'name'. ** Affects: keystone Importance: Wishlist Status: New ** Changed in: keystone Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1354417 Title: new_role_ref() in unit tests adds unused attributes Status in OpenStack Identity (Keystone): New Bug description: new_role_ref() simple calls new_ref() which adds creates an entity with 'id', 'name', 'description' and 'enabled'. Roles should only have 'id' and 'name'. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1354417/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1350593] [NEW] Some assertValidListResponse methods incorrectly handle 'description'
Public bug reported: 'description' is usually an optional attribute in Entities (e.g. Users, Groups etc.). When testing the List methods of such entities, an assert helper method is often used, e.g. assertvalidUserListReponse(). Such assert will call asserValidEntityResponse, which in turn will call the generic method assertValidEntity for each entity in the response. This calling sequence allows for the ability of the top level list assertion method to specific which key fields to check - but if no specification is given then it will check for 'name', 'description' and 'enabled. Since 'description' is optional for most entities, we should not require this to be valid in the any of the entities in the list. This can lead to strange unit test problems when entities created (with a 'description') by a test will cause list response check to fail. This bug was original found by Alexey Miroshkin. ** Affects: keystone Importance: Wishlist Status: New ** Summary changed: - Some assertvalidListResponse methods incorrectly handle 'description' + Some assertValidListResponse methods incorrectly handle 'description' ** 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/1350593 Title: Some assertValidListResponse methods incorrectly handle 'description' Status in OpenStack Identity (Keystone): New Bug description: 'description' is usually an optional attribute in Entities (e.g. Users, Groups etc.). When testing the List methods of such entities, an assert helper method is often used, e.g. assertvalidUserListReponse(). Such assert will call asserValidEntityResponse, which in turn will call the generic method assertValidEntity for each entity in the response. This calling sequence allows for the ability of the top level list assertion method to specific which key fields to check - but if no specification is given then it will check for 'name', 'description' and 'enabled. Since 'description' is optional for most entities, we should not require this to be valid in the any of the entities in the list. This can lead to strange unit test problems when entities created (with a 'description') by a test will cause list response check to fail. This bug was original found by Alexey Miroshkin. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1350593/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1340802] [NEW] test_cache_layer_domain_crud is currently skipped in test_backend_ldap
Public bug reported: We should eventually be able to unskip this by either rewriting the test or provide proper support in LDAP ** 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/1340802 Title: test_cache_layer_domain_crud is currently skipped in test_backend_ldap Status in OpenStack Identity (Keystone): New Bug description: We should eventually be able to unskip this by either rewriting the test or provide proper support in LDAP To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1340802/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1340815] [NEW] Multi-backend domain code/tests could use a bit of tidy up
Public bug reported: The multi-domain backend code has a number of tidy-up items that were deferred from the review: - Re-factoring _set_domain_id_and_mapping() in identity/core.py - Potential relaxation of the constraint that user/group membership cannot cross a backend boundary - Corner case testing for exceptions - Potentially add anything multi-backend test that is in-between the simple and complex tests that have already been defined (e.g. add one that as SQL as the default identity backend, with one LDAP specific domain) - Potentially add a test that puts the SQL driver as a specific backend driver for a domain (since we only support one SQL driver, this is an odd configuration, but still probably worth while) ** 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/1340815 Title: Multi-backend domain code/tests could use a bit of tidy up Status in OpenStack Identity (Keystone): New Bug description: The multi-domain backend code has a number of tidy-up items that were deferred from the review: - Re-factoring _set_domain_id_and_mapping() in identity/core.py - Potential relaxation of the constraint that user/group membership cannot cross a backend boundary - Corner case testing for exceptions - Potentially add anything multi-backend test that is in-between the simple and complex tests that have already been defined (e.g. add one that as SQL as the default identity backend, with one LDAP specific domain) - Potentially add a test that puts the SQL driver as a specific backend driver for a domain (since we only support one SQL driver, this is an odd configuration, but still probably worth while) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1340815/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1339232] [NEW] Debug logs for unit tests appear to contain some corrupted characters
Public bug reported: When running our unit tests as part of jenkins the output file are merged into one output file using subunit. The resulting files appear to contain corrupted characters, e.g.: From a jenkins test: ³+@žS¹_.Ô- ˆ@‹keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_list_projects_for_endpoint_defaultœú¦³+`idS¹_/Û÷Q(@‹keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_list_projects_for_endpoint_defaulttext/plain;charset=utf8pythonlogging:''h™Adding cache-proxy 'keystone.tests.test_cache.CacheIsolatingProxy' to backend. Callback: `keystone.contrib.revoke.core.Manager._trust_callback` subscribed to event `identity.OS-TRUST:trust.deleted`. Callback: `keystone.contrib.revoke.core.Manager._consumer_callback` subscribed to event `identity.OS-OAUTH1:consumer.deleted`. Callback: `keystone.contrib.revoke.core.Manager._access_token_callback` subscribed to event `identity.OS-OAUTH1:access_token.deleted`. Callback: `keystone.contrib.revoke.core.Manager._role_callback` subscribed to event `identity.role.deleted`. Callback: `keystone.contrib.revoke.core.Manager._user_callback` subscribed to event `identity.user.deleted`. . From a local test: test: keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_check_endpoint_project_assoc time: 2014-07-03 17:05:53.955299Z successful: keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_check_endpoint_project_assoc [ multipart Content-Type: text/plain;charset=utf8 pythonlogging:'' 4343 Adding cache-proxy 'keystone.tests.test_cache.CacheIsolatingProxy' to backend. Callback: `keystone.contrib.revoke.core.Manager._trust_callback` subscribed to event `identity.OS-TRUST:trust.deleted` Callback: `keystone.contrib.revoke.core.Manager._consumer_callback` subscribed to event `identity.OS-OAUTH1:consumer.deleted`. Callback: `keystone.contrib.revoke.core.Manager._access_token_callback` subscribed to event `identity.OS-OAUTH1:access_token.deleted`. Callback: `keystone.contrib.revoke.core.Manager._role_callback` subscribed to event `identity.role.deleted`. Callback: `keystone.contrib.revoke.core.Manager._user_callback` subscribed to event `identity.user.deleted`. . Is this some kind of artefact of not handling the subunit output correctly? ** Affects: keystone Importance: Medium 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/1339232 Title: Debug logs for unit tests appear to contain some corrupted characters Status in OpenStack Identity (Keystone): New Bug description: When running our unit tests as part of jenkins the output file are merged into one output file using subunit. The resulting files appear to contain corrupted characters, e.g.: From a jenkins test: ³+@žS¹_.Ô- ˆ@‹keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_list_projects_for_endpoint_defaultœú¦³+`idS¹_/Û÷Q(@‹keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_list_projects_for_endpoint_defaulttext/plain;charset=utf8pythonlogging:''h™Adding cache-proxy 'keystone.tests.test_cache.CacheIsolatingProxy' to backend. Callback: `keystone.contrib.revoke.core.Manager._trust_callback` subscribed to event `identity.OS-TRUST:trust.deleted`. Callback: `keystone.contrib.revoke.core.Manager._consumer_callback` subscribed to event `identity.OS-OAUTH1:consumer.deleted`. Callback: `keystone.contrib.revoke.core.Manager._access_token_callback` subscribed to event `identity.OS-OAUTH1:access_token.deleted`. Callback: `keystone.contrib.revoke.core.Manager._role_callback` subscribed to event `identity.role.deleted`. Callback: `keystone.contrib.revoke.core.Manager._user_callback` subscribed to event `identity.user.deleted`. . From a local test: test: keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_check_endpoint_project_assoc time: 2014-07-03 17:05:53.955299Z successful: keystone.tests.test_associate_project_endpoint_extension.AssociateEndpointProjectFilterCRUDTestCase.test_check_endpoint_project_assoc [ multipart Content-Type: text/plain;charset=utf8 pythonlogging:'' 4343 Adding cache-proxy 'keystone.tests.test_cache.CacheIsolatingProxy' to backend. Callback: `keystone.contrib.revoke.core.Manager._trust_callback` subscribed to event `identity.OS-TRUST:trust.deleted` Callback: `keystone.contrib.revoke.core.Manager._consumer_callback` subscribed to event `identity.OS-OAUTH1:consumer.deleted`. Callback: `keystone.contrib.revoke.core.Manager._access_token_callback` subscribed to event `identity.OS-OAUTH1:access_token.deleted`.
[Yahoo-eng-team] [Bug 1291393] [NEW] domain_id in User/Group/Project should be immutable
Public bug reported: Today we allow the domain_id in User, Group and Project entities to be updated….effectively moving the entity between domains. With today's policy capability this represents a potential security hole if you are trying to enforce strict domain admin type of roles. We should allow a cloud provider to disable this current update ability…and make the domain_id attribute immutable in the same way we do for the id of the entity. ** Affects: keystone Importance: High Assignee: Henry Nash (henry-nash) 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/1291393 Title: domain_id in User/Group/Project should be immutable Status in OpenStack Identity (Keystone): New Bug description: Today we allow the domain_id in User, Group and Project entities to be updated….effectively moving the entity between domains. With today's policy capability this represents a potential security hole if you are trying to enforce strict domain admin type of roles. We should allow a cloud provider to disable this current update ability…and make the domain_id attribute immutable in the same way we do for the id of the entity. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1291393/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
