Open Stack

On Mon, Sep 24, 2012 at 4:04 PM, Adam Young <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?


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


>
> 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>
> wrote:
>
> On Mon, Sep 24, 2012 at 6:13 AM, Alan Pevec <apevec at gmail.com> wrote:
>
>> On Mon, Sep 24, 2012 at 10:45 AM, Thierry Carrez <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
>> 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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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/d170ff4e/attachment.html>