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

Monty Taylor mordred at inaugust.com
Mon Feb 27 15:49:21 UTC 2017

On 02/27/2017 09:36 AM, Morgan Fainberg wrote:
> On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
>     On 02/27/2017 10:22 AM, Morgan Fainberg wrote:
>     <snip>
>     > 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.
>     >
>     > The best we can provide is a way to build the instances from
>     > keystoneauth that does not include that hack.
>     >
>     > 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).
>     Ok, I'm going to go back to not using the version= parameter then.
>     Because it's not actually doing the right thing.
>     I also am a bit concerned that basically through some client changes
>     that people didn't understand, we've missed a break in the upstream
>     transition that will impact real clouds. :(
> 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.
> The adapter should make things a lot easier once the lifting is done. 

Yah. Consider me to be on this. Looking at the code you've got to make
intra-openstack rest calls makes me want to poke out my own eyeballs. It
does _not_ have to be this hard or this brittle.

It'll likely take a few days and a thing or two to unwind.

More information about the OpenStack-dev mailing list