Open Stack

On 01/08/2015 07:01 PM, Morgan Fainberg wrote:
> 
>> On Jan 8, 2015, at 3:56 PM, Sean Dague <sean at dague.net> wrote:
>>
>> On 01/08/2015 06:29 PM, Morgan Fainberg wrote:
>>> As of Juno all projects are using the new keystonemiddleware package for auth_token middleware. Recently we’ve been running into issues with maintenance of the now frozen (and deprecated) keystoneclient.middleware.auth_token code. Ideally all deployments should move over to the new package. In some cases this may or may not be as feasible due to requirement changes when using the new middleware package on particularly old deployments (Grizzly, Havana, etc).
>>>
>>> The Keystone team is looking for the best way to support our deployer community. In a perfect world we would be able to convert icehouse deployments to the new middleware package and instruct deployers to use either an older keystoneclient or convert to keystonemiddleware if they want the newest keystoneclient lib (regardless of their deployment release). For releases older than Icehouse (EOLd) there is no way to communicate in the repositories/tags a change to require keystonemiddleware.
>>>
>>> There are 2 viable options to get to where we only have one version of the keystonemiddleware to maintain (which for a number of reasons, primarily relating to security concerns is important).
>>>
>>> 1) Work to update Icehouse to include the keystonemiddleware package for the next stable release. Sometime after this stable release remove the auth_token (and other middlewares) from keystoneclient. The biggest downside is this adds new dependencies in an old release, which is poor for packaging and deployers (making sure paste-ini is updated etc).
>>>
>>> 2) Plan to remove auth_token from keystoneclient once icehouse hits EOL. This is a better experience for our deployer base, but does not solve the issues around solid testing with the auth_token middleware from keystoneclient (except for the stable-icehouse devstack-gate jobs).
>>>
>>> I am looking for insight, preferences, and other options from the community and the TC. I will propose this topic for the next TC meeting so that we can have a clear view on how to handle this in the most appropriate way that imparts the best balance between maintainability, security, and experience for the OpenStack providers, deployers, and users.
>>
>> So, ignoring the code a bit for a second, what are the interfaces which
>> are exposed that we're going to run into a breaking change here?
>>
>> 	-Sean
>>
> 
> 
> There are some configuration options provided by auth_token middleware and the paste-ini files load keystoneclient.middleware.auth_token to handle validation of Tokens then converting the token data to an auth_context passed down to the service.
> 
> There are no external (should be no) interfaces beyond the __call__ of the middleware and options themselves.

Ok, so ... if this isn't out on the network, is the only reason this is
an issue is that keystoneclient version is unbounded in the stable branches?

	-Sean

-- 
Sean Dague
http://dague.net