> On Jan 8, 2015, at 3:56 PM, Sean Dague <s...@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 

There are no external (should be no) interfaces beyond the __call__ of the 
middleware and options themselves.


OpenStack-dev mailing list

Reply via email to