<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 27 February 2017 at 08:56, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We recently implemented a Nova feature around validating that project_id<br>
for quotas we real in keystone. After that merged, trippleo builds<br>
started to fail because their undercloud did not specify the 'identity'<br>
service as the unversioned endpoint.<br>
<br>
<a href="https://github.com/openstack/nova/blob/8b498ce199ac4acd94eb33a7f47c05ee0c743c34/nova/api/openstack/identity.py#L34-L36" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>nova/blob/<wbr>8b498ce199ac4acd94eb33a7f47c05<wbr>ee0c743c34/nova/api/openstack/<wbr>identity.py#L34-L36</a><br>
- (code merged in Nova).<br>
<br>
After some debug, it was clear that '/v2.0/v3/projects/...' was what was<br>
being called. And after lots of conferring in the Keystone room, we<br>
definitely made sure that the code in question was correct. The thing I<br>
wanted to do was make the failure more clear.<br>
<br>
The suggestion was made to use the following code approach:<br>
<br>
<a href="https://review.openstack.org/#/c/438049/6/nova/api/openstack/identity.py" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/438049/6/nova/api/<wbr>openstack/identity.py</a><br>
<br>
resp = sess.get('/projects/%s' % project_id,<br>
endpoint_filter={<br>
'service_type': 'identity',<br>
'version': (3, 0)<br>
},<br>
raise_exc=False)<br>
<br>
<br>
However, I tested that manually with an identity =><br>
http://............/v2.0 endpoint, and it passes. Which confused me.<br>
<br>
Until I found this -<br>
<a href="https://github.com/openstack/keystoneauth/blob/3364703d3b0e529f7c1b7d1d8ea81726c4f5f121/keystoneauth1/discover.py#L313" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>keystoneauth/blob/<wbr>3364703d3b0e529f7c1b7d1d8ea817<wbr>26c4f5f121/keystoneauth1/<wbr>discover.py#L313</a><br>
<br>
keystonauth is specifically coding around the keystone transition from a<br>
versioned /v2.0 endpoint to an unversioned one.....<br>
<br>
<br>
While that is good for the python ecosystem using it, it's actually<br>
*quite* bad for the rest of our ecosystem (direct REST, java, ruby, go,<br>
js, php), because it means that all other facilities need the same work<br>
around. I actually wonder if this is one of the in the field reasons for<br>
why the transition from v2 -> v3 is going slow. That's actually going to<br>
potentially break a lot of software.<br>
<br>
It feels like this whole discovery version hack bit should be removed -<br>
<a href="https://review.openstack.org/#/c/438483/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/438483/</a>. It also feels like a migration<br>
path for non python software in changing the catalog entries needs to be<br>
figured out as well.<br>
<br>
I think on the Nova side we need to go back to looking for bogus<br>
endpoint because we don't want issues like this hidden from us.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
-Sean</font></span></blockquote><div><br></div><div><span style="color:rgb(0,0,0)">So I would completely agree, I would like to see this behaviour removed. </span>However it was done very intentionally - and at the time it was written it was needed.<br><br></div><div>This is one of a number of situations where keystoneauth tried its best to paper over inconsistencies in OpenStack APIs because to various levels of effectiveness almost all the python clients were doing this. Any whilst we have slowly pushed the documentation and standard deployment procedures to unversioned URLs whilst this hack was maintained in keystoneauth we didn't have to fix it individually for every client.<br><br></div><div>Where python and keystoneauth are different from every other language is that the services themselves are written in python and using these libraries and inter-service communication had to continue to work throughout the transition. You may remember the fun we had trying to change to v3 auth and unversioned URLs in devstack? This hack is what made it possible at all. As you say this is extremely difficult for other languages, but something there isn't a solution for whilst this transition is in place.<br><br></div><div>Anyway a few cycles later we are in a different position and a new service such as the placement API can decide that it shouldn't work at all if the catalog isn't configured as OpenStack advises. This is great! We can effectively force deployments to transition to unversioned URLs. We can't change the default behaviour in keystoneauth but it should be relatively easy to give you an adapter that doesn't do this. Probably something like [1]. I also filed it as a bug, which links to this thread [2], but could otherwise do with some more detail. <br><br></div><div>Long story short, sorry but it'll have to be a new flag. Yes, keystoneauth is supposed to be a low-level request maker, but it is also trying to paper over a number of historical bad decisions so at the very least the user experience is correct and we don't have clients re-inventing it themselves.<br></div><div><br>[1] <a href="https://review.openstack.org/#/c/438788/">https://review.openstack.org/#/c/438788/</a> <br>[2] <a href="https://bugs.launchpad.net/keystoneauth/+bug/1668484">https://bugs.launchpad.net/keystoneauth/+bug/1668484</a><br></div></div></div></div>