That was a copy paste error. The response was meant to be: Yes, that is the issue, unbounded version on the stable branches.
--Morgan Sent via mobile > On Jan 8, 2015, at 22:57, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > >>> 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
