[openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

Sean Dague sean at dague.net
Mon Feb 27 13:56:32 UTC 2017

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.

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


        resp = sess.get('/projects/%s' % project_id,
                            'service_type': 'identity',
                            'version': (3, 0)

However, I tested that manually with an identity =>
http://............/v2.0 endpoint, and it passes. Which confused me.

Until I found this -

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 Dague

More information about the OpenStack-dev mailing list