Open Stack

Dean Troyer wrote:
> On Fri, Jan 9, 2015 at 4:22 AM, Thierry Carrez <thierry at openstack.org
> <mailto:thierry at openstack.org>> wrote:
> 
>     This is probably a very dumb question, but could you explain why
>     keystoneclient.middleware can't map to keystonemiddleware functions
>     (adding keystonemiddleware as a dependency of future keystoneclient)? At
>     first glance that would allow to remove dead duplicated code while
>     ensuring compatibility for as long as we need to support those old
>     releases...
> 
> Part of the reason for moving keystonemiddleware out of
> keystonemiddleware was to do the reverse, have a keystoneclient install
> NOT bring in auth_token.  I doubt there will be anything other than
> servers that need keystonemiddleware installed whereas quite a few
> clients will not want it at all.

Sure, that should clearly still be the end goal... The idea would be to
keep deprecated functions in the client lib until we consider those
releases that need them truly dead. Not saying it's the best option
ever, was just curious why it was not listed in the proposed options :)

> I'm on the fence about changing stable requirements...if we imagine
> keystonemiddleware is not an OpenStack project this wouldn't be the
> first time we've had to do that when things change out from under us. 
> But I hate doing that to ourselves...

This is not about changing "stable requirements": havana servers would
still depend on "python-keystoneclient" like they always did. If you use
an old version of that you are covered, and if you use a new version of
that, *that* would pull keystonemiddleware as a new requirement. So this
is about temporarily changing future keystoneclient requirements to
avoid double maintenance of code while preserving compatibility.

-- 
Thierry Carrez (ttx)