Open Stack

The auth_token middleware should be its own package from a distribution 
perspective, but should not be in Keystone Client.

auth_token middle ware now depends on  cryptographic routines that are 
shared with the server side. That is why we cannot simply distribute a 
single auth_token.py file.

There is a difference between running the CLI and authenticating against 
Keystone.  Keystone Client is the CLI.  It is for administering the 
Keystone server.  auth_token middleware is for a web service to verify 
tokens against keystone, and to query the service catalog.

For example, glance uses auth_token middleware.  It does not use any of 
the Keystone client code.

 From a development perspective auth_token is tightly coupled with the 
Keystone server.  As such, the Keystone team should continue to maintain 
code review and approval authority over it, thus it should not move in 
to Openstack common, either.

For packaged distributions,  we should build out of a single repository 
into a proper package breakdown.  The correct package breakdown for 
Keystone is:  server, CLI, auth_token, and common. While the CLI comes 
from a different git repo, there is no reason to split out the other pieces.

auth_token is not the only middleware piece provided by Keystone. It is 
merely the largest and most tightly integrated with the other openstack 
components.

We should fix the packaging of the autho_token middleware, but leave the 
source code where it currently resides.



On 09/24/2012 12:55 PM, heckj wrote:
> Seeing as it's a client for keystone, just like the CLI mechanisms, 
> keystoneclient is a good choice - thanks for suggesting it Brian!
>
> I've created a new blueprint - 
> https://blueprints.launchpad.net/keystone/+spec/authtoken-to-keystoneclient-repo
> and we'll review this at the keystone meeting tomorrow 
> (http://wiki.openstack.org/Meetings/KeystoneMeeting)
>
> -joe
>
>
> On Sep 24, 2012, at 3:27 AM, Doug Hellmann 
> <doug.hellmann at dreamhost.com <mailto:doug.hellmann at dreamhost.com>> wrote:
>> On Mon, Sep 24, 2012 at 6:13 AM, Alan Pevec <apevec at gmail.com 
>> <mailto:apevec at gmail.com>> wrote:
>>
>>     On Mon, Sep 24, 2012 at 10:45 AM, Thierry Carrez
>>     <thierry at openstack.org <mailto:thierry at openstack.org>> wrote:
>>     > Brian Waldon wrote:
>>     >> The auth_token middleware shouldn't live in the Keystone
>>     source tree. It is not intended to be used alongside any of the
>>     Keystone code as it gets pulled in to every service *but*
>>     Keystone. It is super frustrating to have to install all of
>>     Keystone just to get this one piece of code. As this middleware
>>     is just a client, I am proposing we move it into the existing
>>     keystone client library - python-keystoneclient. What are the
>>     immediate feelings here?
>>     >
>>     > Distributions can solve this by creating multiple binary
>>     packages from
>>     > the same source package,
>>
>>     I did that in Fedora for Essex, but it broke post folsom-2 due to new
>>     intra-keystone dependencies in auth-token middleware:
>>     https://bugzilla.redhat.com/show_bug.cgi?id=844508
>>
>>     There's also an issue with python subpackages sharing python
>>     namespace
>>     - who owns overlapping __init__.py ?
>>
>>
>> One common way to solve that is by using a namespace package at the 
>> top level.
>>
>> Doug
>>
>>     Best would be if auth-token is moved out of keystone.middleware,
>>     there
>>     are stuff imported[1] not required by auth-token.
>>
>>     Alan
>>
>>
>>     [1]
>>     https://github.com/openstack/keystone/blob/master/keystone/middleware/__init__.py#L17
>>
>>     _______________________________________________
>>     OpenStack-dev mailing list
>>     OpenStack-dev at lists.openstack.org
>>     <mailto:OpenStack-dev at lists.openstack.org>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org 
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120924/2bc6d598/attachment-0001.html>