Bug 867029 – Update to the latest Essex stable release 2012.1.3

Bug 867029 - Update to the latest Essex stable release 2012.1.3

Summary:	Update to the latest Essex stable release 2012.1.3

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat OpenStack
Classification:	Red Hat
Component:	openstack-keystone (Show other bugs)
Sub Component:
Version:	1.0 (Essex)
Hardware:	Unspecified Unspecified

Priority	unspecified Severity unspecified
Target Milestone:	---
Target Release:	---
Assigned To:	Alan Pevec
QA Contact:	Jaroslav Henner
Docs Contact:

URL:
Whiteboard:
Keywords:	Rebase

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2012-10-16 11:08 EDT by Alan Pevec
Modified:	2012-12-10 16:03 EST (History)
CC List:	1 user (show)

See Also:
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 16:03:02 EST
Type:	Bug
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Alan Pevec 2012-10-16 11:08:26 EDT

Last official stable/essex release 2012.1.3 is available, which contains, in addition to security fixes already included in openstack-keystone-2012.1.2-4, following bugfixes:

* return roles from authenticate in ldap backend (lp#1035428)
* utf-8 encode user keys in memcache (lp#1056373)

Comment 2 Jaroslav Henner 2012-10-23 07:50:48 EDT

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.

Comment 3 Jaroslav Henner 2012-10-23 08:18:16 EDT

I ran our tests with this. No regressions found.

Comment 4 Alan Pevec 2012-10-23 10:21:06 EDT

(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.

Comment 5 Jaroslav Henner 2012-10-25 06:30:43 EDT

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.

Comment 7 errata-xmlrpc 2012-12-10 16:03:02 EST

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

Note You need to log in before you can comment on or make changes to this bug.