[openstack-dev] Keystone auth_token middleware

Monty Taylor mordred at inaugust.com
Tue Sep 25 01:19:25 UTC 2012



On 09/24/2012 07:52 PM, Dolph Mathews wrote:
> 
> On Mon, Sep 24, 2012 at 4:04 PM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
> 
>     The auth_token middleware should be its own package from a
>     distribution perspective, but should not be in Keystone Client. 
> 
> 
> Agree on your first point.
>  
> 
>     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. 
> 
> 
> Hmm, should we (or can we?) extract common dependencies into a whole new
> python package (keystonecommon?) that can be consumed by both keystone &
> auth_token?

Can, yes. Should, abstain.

>     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.
> 
> 
> keystoneclient is really a python API first, and a CLI second. The CLI,
> end-user authentication, token validation, etc, should all be performed
> via keystoneclient.

++

>     For example, glance uses auth_token middleware.  It does not use any
>     of the Keystone client code.
> 
> 
> auth_token re-implements a subset of keystoneclient's functionality --
> I'd like to see auth_token rewritten to consume keystoneclient directly,
> which would vastly simplify both auth_token and overall maintenance.
>  
> 
>     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. 
> 
> 
> Coupled yes, definitely. But I wouldn't describe it as "tight," the last
> I looked?
>  
> 
>     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.
> 
> 
> They could/should be different python package namespaces however, which
> I understand is difficult to do with a single git repo -- due to either
> gerrit/jenkins?

We generally do not allow multiple python packages per git repo (that
is, more than one directory each with its own setup.py) But the thing
is, if you want a package with its own setup.py, make it its own repo
with its own lifecycle as well, release it to places like pypi, and then
consume it in other things. We have done this already with the split of
client libs from servers and I think we all pretty much get how it
works. Splitting an additional piece out into an additional repo would
not  be hard.

We can do what we need to in gerrit/jenkins. Let's start first with
deciding theoretically what a perfect world would be, and then we can
work on discussing how we'll implement that.

It sounds to me like there is a thing called keystoneclient, a think
called keystone, and a thing called auth_token (please let's fine a
better name if we break it out) One of the things we want our of life is
for auth_token and keystone to both consume keystoneclient. We also may
want multiple other projects to consume auth_token. Yeah?

To me that sounds like we want not only a repo for auth_token, but a
pypi entity that other projects can potentially consume. ne pas?

>     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
>>     <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 <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
> 



More information about the OpenStack-dev mailing list