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
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
