Bug 867029
Summary: | Update to the latest Essex stable release 2012.1.3 | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Alan Pevec <apevec> |
Component: | openstack-keystone | Assignee: | Alan Pevec <apevec> |
Status: | CLOSED ERRATA | QA Contact: | Jaroslav Henner <jhenner> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.0 (Essex) | CC: | ayoung |
Target Milestone: | --- | Keywords: | Rebase |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | openstack-keystone-2012.1.3-1.el6 | Doc Type: | Rebase: Bug Fixes and Enhancements |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-10 21:03:02 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Alan Pevec
2012-10-16 15:08:26 UTC
lp#1056373 keystone user-role-add --user 'e279fc407631463399c5b87efda602e4' --role 0a2dc9d4a87d487b8edb97450fe26af5 --tenant 625c84d3fad745c785f1ab64fdc45047 returned nothing, user got added, however what I would expect is that following should work: keystone user-role-add --user 'Příliž luťoučký kůň zahýkal' --role admin --tenant admin 'ascii' codec can't decode byte 0xc5 in position 22: ordinal not in range(128) but this is another story -- it accepts ids instead of names, as option-names would suggest. I ran our tests with this. No regressions found. (In reply to comment #2) > but this is another story -- it accepts ids instead of names, as > option-names would suggest. Yeah, during the Folsom cycle, all parameter names were renamed to include -id to make this clear: usage: keystone user-role-add --user-id <user-id> --role-id <role-id> [--tenant-id <tenant-id>] BTW this breaks old scripts, so it's one of the things for the E->F upgrade notes. Atilla Fazekasz was verifying the LDAP&roles bug. It is working -- roles are in the response to POST for the token, but he had other problems: # 1. email - default email attribute instead of the standard mail # 2. without specifieing the *_tree_dn , it concretenesses in the wrong order # 3. tenantId is not the member of either ['person', 'inetOrgPerson'] # 4. "enabled" is not the member of the groupOfObjects Class IMHO we can let this proceed to VERIFIED and raise other bugs about the other problems. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-1556.html |