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 Dague

OpenStack-dev mailing list

Reply via email to