That was a copy paste error. The response was meant to be:

Yes, that is the issue, unbounded version on the stable branches. 


Sent via mobile

> On Jan 8, 2015, at 22:57, Morgan Fainberg <> wrote:
>>> On Jan 8, 2015, at 16:10, Sean Dague <> wrote:
>>>> On 01/08/2015 07:01 PM, Morgan Fainberg wrote:
>>>> On Jan 8, 2015, at 3:56 PM, Sean Dague <> 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?
> That is a fair assessment of the situation. 
> --Morgan

OpenStack-dev mailing list

Reply via email to