Open Stack

> On Jan 9, 2015, at 5:28 AM, Thierry Carrez <thierry at openstack.org> wrote:
> 
> 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.
> 

There is a simple and more technical reason keystonemiddleware cannot be imported by keystoneclient: It would be a circular dependency. Keystonemiddleware makes use of keystoneclient cms (PKI token encoding/decoding) code, the keystoneclient Session object, and the auth_plugins. Simply put, without further splitting apart keystoneclient into sub-modules (again requiring stable changes, and a lot more upheaval), the libraries do not lend themselves to cross import.

Dean’s point is accurate, the goal is to make it so that keystoneclient doesn’t need to pull in all of the server requirements that middleware needs to run (the whole reason for the split).

Cheers,
—Morgan