Open Stack

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