<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 7:26 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">On 02/27/2017 10:22 AM, Morgan Fainberg wrote:<br>
<snip><br>
<span class="">> I agree we should kill the discovery hack, however that is a break in<br>
> the keystoneauth contract. Simply put, we cannot. Keystoneauth is one of<br>
> the few things (similar to how shade works) where behavior, exposed<br>
> elements, etc are considered a strict contract that will not change. If<br>
> we could have avoided stevedore and PBR we would have.<br>
><br>
> The best we can provide is a way to build the instances from<br>
> keystoneauth that does not include that hack.<br>
><br>
> The short is, we can't remove it. Similar to how we cannot change the<br>
> raise of exceptions for non-200 responses (the behavior is already encoded).<br>
<br>
</span>Ok, I'm going to go back to not using the version= parameter then.<br>
Because it's not actually doing the right thing.<br>
<br>
I also am a bit concerned that basically through some client changes<br>
that people didn't understand, we've missed a break in the upstream<br>
transition that will impact real clouds. :(<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>We can make an adapter that does what you want (requests adapters are cool). I was just chatting with Monty about this, and we can help you out on this front.</div><div><br></div><div>The adapter should make things a lot easier once the lifting is done. </div></div></div></div>