> On Jan 8, 2015, at 16:10, Sean Dague <s...@dague.net> wrote: > >> On 01/08/2015 07:01 PM, Morgan Fainberg wrote: >> >>> 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. > > Ok, so ... if this isn't out on the network, is the only reason this is > an issue is that keystoneclient version is unbounded in the stable branches? >
That is a fair assessment of the situation. --Morgan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
