OpenStack Identity (keystone)

Bug #1039567
Comment #5

Comment 5 for bug 1039567

Revision history for this message

Adam Young (ayoung) wrote on 2012-11-06: Re: [Bug 1039567] Re: auth_token middleware should be stand alone

On 11/06/2012 07:35 AM, Henry Nash wrote:
> So here's the High Level plan for fixing this:
>
> 1) Move auth_token from keystone to keystone client, so that other projects only need to have access to the client modules, not the server itself
> 2) Change the various paste files to find this in the new location.
> 3) Do the above in a sequence that doesn't break anything
>
> Detail of the changes:
>
> a) Unfortunately, auth_token has grown some roots in the keystone server that we need to cut, namely:
> - It references some keystone.openstack.common items (jsonutils, timeutils, cfg) that are not in keystoneclient.openstack.common, so we'll add those to the client (and update its openstack-common.conf file accordingly)
> - It also references cms, utils (and indirectly logging) from keystone.common. Now for utils, the only thing that is referenced is hash_signed_token - and nobody else in the server uses this. So I propose we move this function to keystoneclient.utils and leave keystone.common.utils where it is. cms needs to move (but also be accessed by keystone). For cms and auth_token, we need to ensure that when running as part of keystone itself then we use the keystone.common.logging (which is a wrapper round the standard logger), while in all other cases we are just going straight to the standard logger.
> b) We'll start by making the above changes in keystoneclient - but leave everything hooked up to the original ones in keystone - so the initial set of patches will be benign
> c) We'll add the tests to the client side and ensure that they call and run the new code and all work fine
> d) We'll then change devstack and the paste files in the other projects to point keystoneclient rather than keystone for the authorization code.
> e) Finally we'll retire the keystone version of auth_token and make keystone reference the client of any the files we have moved
>
> Expect a series of patches to execute the above, as well as additional
> bugs/changes opened on the other projects to modify their paste files
>
ACK

On 11/06/2012 07:35 AM, Henry Nash wrote:
> So here's the High Level plan for fixing this:
>
> 1) Move auth_token from keystone to keystone client, so that other projects only need to have access to the client modules, not the server itself
> 2) Change the various paste files to find this in the new location.
> 3) Do the above in a sequence that doesn't break anything
>
> Detail of the changes:
>
> a) Unfortunately, auth_token has grown some roots in the keystone server that we need to cut, namely:
> - It references some keystone.openstack.common items (jsonutils, timeutils, cfg) that are not in keystoneclient.openstack.common, so we'll add those to the client (and update its openstack-common.conf file accordingly)
> - It also references cms, utils (and indirectly logging) from keystone.common.  Now for utils, the only thing that is referenced is hash_signed_token - and nobody else in the server uses this.  So I propose we move this function to keystoneclient.utils and leave keystone.common.utils where it is.  cms needs to move (but also be accessed by keystone).  For cms and auth_token, we need to ensure that when running as part of keystone itself then we use the keystone.common.logging (which is a wrapper round the standard logger), while in all other cases we are just going straight to the standard logger.
> b) We'll start by making the above changes in keystoneclient - but leave everything hooked up to the original ones in keystone - so the initial set of patches will be benign
> c) We'll add the tests to the client side and ensure that they call and run the new code and all work fine
> d) We'll then change devstack and the paste files in the other projects to point keystoneclient rather than keystone for the authorization code.
> e) Finally we'll retire the keystone version of auth_token and make keystone reference the client of any the files we have moved
>
> Expect a series of patches to execute the above, as well as additional
> bugs/changes opened on the other projects to modify their paste files
>
ACK