Description of problem: In ESSEX it is possible to break access to horizon (and probably other things) when attempting to manually create an invalid endpoint using 'keystone endpoint-create ...' with the wrong CLI options and possibly the wrong values passed to those options. Version-Release number of selected component (if applicable): Essex How reproducible: Every Steps to Reproduce: 1.created an incompletely endpoint thusly (note: no publicurl, adminurl, and internalurl): keystone endpoint-create --region RegionOne --service_id 6a0447de95554667 8dac94324c394956 2. Attempt to login via the horizon web UI 3. Actual results: Permission denied Expected results: Access granted Additional info: I've also opened this bug upstream: https://bugs.launchpad.net/keystone/+bug/1080862
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
If this is fixed in Folsom, that's ok with me.
Reopening since I did the same on Folsom: [para@virtual-rhel-beta ~(keystone_admin)]$ keystone service-create --name=glance --type=image --description="Glance Image Service" +-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | description | Glance Image Service | | id | ac82850b67284a6f954dca3498a04bb4 | | name | glance | | type | image | +-------------+----------------------------------+ [para@virtual-rhel-beta ~(keystone_admin)]$ keystone endpoint-create --service_id ac82850b67284a6f954dca3498a04bb4 +-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | adminurl | | | id | 7d6cec22e05b4777b485464d36fa12e5 | | internalurl | | | publicurl | | | region | regionOne | | service_id | ac82850b67284a6f954dca3498a04bb4 | +-------------+----------------------------------+ [para@virtual-rhel-beta ~(keystone_admin)]$ rpm -qa *keystone openstack-keystone-2012.2.1-1.el6ost.noarch python-keystone-2012.2.1-1.el6ost.noarch
(In reply to comment #5) > Reopening since I did the same on Folsom: But it doesn't "break access to horizon (and probably other things)" right? Validation part is not critical, and would be inherited when fixed upstream.
No, it didn't break access to horizon. I agree that it's not critical.
Upstream NACK means this will not be fixed. It is not possible to validate the Endpoint, as the endpoint might not be available at time of creation.