> 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 service. There are no external (should be no) interfaces beyond the __call__ of the middleware and options themselves. Cheers, —Morgan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
