Open Stack

On 01/09/2015 01:59 AM, Morgan Fainberg wrote:
> That was a copy paste error. The response was meant to be:
> 
> Yes, that is the issue, unbounded version on the stable branches. 

So if that is the root issue, there are other fixes. Our current policy
of keeping clients uncapped on stable branches is due to trying to do a
few too many things at once in the test environment.

Some history:

There are basically no explicit live tests for clients libraries / cli
at all. It remains a hole. As a project we've fallen back to secondary
testing of those clients through the fact that OpenStack services
implicitly use them to talk to each other (and they used to be inside a
small amount of tempest code, but that's been removed).

As a policy we expect:

CLI/LIBS to work with both newer and older clouds. Which totally makes
sense. Especially when you think about the use case like nodepool where
you have 1 process that talks to 2 clouds at different levels of
OpenStack at the same time.

Barring any real testing of the CLI/LIBS we do the "install latest libs
in stable/juno stacks" as a fall back.

But... what that actually creates is a stable/icehouse env with the
latest client code being used to talk between components (i.e. from nova
-> cinder). Which I am sure is how basically zero people in the world
have their clouds. You don't go randomly upping libraries in these
environments unless you have to. It also actually allows backports to
require newer library features which wouldn't exist there.


So... we could (and probably should) cap libraries on stable branches.
There are definitely a few dragons there, at least one of which Doug
discovered in that you can't really do this for only a slice of the
libraries, as if any are allowed to roll forward they can stick you in
conflicting requirements land. We know they all worked at a revision set
when we released, we need to capture that and move on.

This would allow the keystone team to drop having to carry that dead code.

Clearly we also need to actually have the clients test themselves
against OpenStack explicitly, not just by accident. But that's a bigger
challenge to overcome.

	-Sean

> 
> --Morgan
> 
> Sent via mobile
> 
>> On Jan 8, 2015, at 22:57, Morgan Fainberg <morgan.fainberg at gmail.com> wrote:
>>
>>
>>
>>>> On Jan 8, 2015, at 16:10, Sean Dague <sean at dague.net> wrote:
>>>>
>>>>> On 01/08/2015 07:01 PM, Morgan Fainberg wrote:
>>>>>
>>>>> On Jan 8, 2015, at 3:56 PM, Sean Dague <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net