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. Cheers, Morgan Fainberg _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
