<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 5:56 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;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="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I agree we should kill the discovery hack, however that is a break in the keystoneauth contract. Simply put, we cannot. Keystoneauth is one of the few things (similar to how shade works) where behavior, exposed elements, etc are considered a strict contract that will not change. If we could have avoided stevedore and PBR we would have.</div><div><br></div><div>The best we can provide is a way to build the instances from keystoneauth that does not include that hack.</div><div><br></div><div>The short is, we can't remove it. Similar to how we cannot change the raise of exceptions for non-200 responses (the behavior is already encoded).</div><div><br></div><div>--Morgan</div></div></div></div>