We recently implemented a Nova feature around validating that project_id for quotas we real in keystone. After that merged, trippleo builds started to fail because their undercloud did not specify the 'identity' service as the unversioned endpoint.
https://github.com/openstack/nova/blob/8b498ce199ac4acd94eb33a7f47c05ee0c743c34/nova/api/openstack/identity.py#L34-L36 - (code merged in Nova). After some debug, it was clear that '/v2.0/v3/projects/...' was what was being called. And after lots of conferring in the Keystone room, we definitely made sure that the code in question was correct. The thing I wanted to do was make the failure more clear. The suggestion was made to use the following code approach: https://review.openstack.org/#/c/438049/6/nova/api/openstack/identity.py resp = sess.get('/projects/%s' % project_id, endpoint_filter={ 'service_type': 'identity', 'version': (3, 0) }, raise_exc=False) However, I tested that manually with an identity => http://............/v2.0 endpoint, and it passes. Which confused me. Until I found this - https://github.com/openstack/keystoneauth/blob/3364703d3b0e529f7c1b7d1d8ea81726c4f5f121/keystoneauth1/discover.py#L313 keystonauth is specifically coding around the keystone transition from a versioned /v2.0 endpoint to an unversioned one..... While that is good for the python ecosystem using it, it's actually *quite* bad for the rest of our ecosystem (direct REST, java, ruby, go, js, php), because it means that all other facilities need the same work around. I actually wonder if this is one of the in the field reasons for why the transition from v2 -> v3 is going slow. That's actually going to potentially break a lot of software. It feels like this whole discovery version hack bit should be removed - https://review.openstack.org/#/c/438483/. It also feels like a migration path for non python software in changing the catalog entries needs to be figured out as well. I think on the Nova side we need to go back to looking for bogus endpoint because we don't want issues like this hidden from us. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
