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.
This is probably a very dumb question, but could you explain why keystoneclient.middleware can't map to keystonemiddleware functions (adding keystonemiddleware as a dependency of future keystoneclient)? At first glance that would allow to remove dead duplicated code while ensuring compatibility for as long as we need to support those old releases... -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
