<div><br></div><div><div class="gmail_quote">On Mon, Sep 24, 2012 at 4:04 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>The auth_token middleware should be its
own package from a distribution perspective, but should not be in
Keystone Client. <br>
<br></div></div></blockquote><div><br></div><div>Agree on your first point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>
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. <br>
<br></div></div></blockquote><div><br></div><div><div>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?</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
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.<br>
<br></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
For example, glance uses auth_token middleware. It does not use
any of the Keystone client code.<br>
<br></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
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. <br>
<br></div></div></blockquote><div><br></div><div>Coupled yes, definitely. But I wouldn't describe it as "tight," the last I looked?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div>
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.<br></div></div></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
<br>
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. <br>
<br>
We should fix the packaging of the autho_token middleware, but
leave the source code where it currently resides.<div><div><br>
<br>
<br>
<br>
On 09/24/2012 12:55 PM, heckj wrote:<br>
</div></div></div><div><div>
<blockquote type="cite">
Seeing as it's a client for keystone, just like the CLI
mechanisms, keystoneclient is a good choice - thanks for
suggesting it Brian!
<div><br>
</div>
<div>I've created a new blueprint - <a href="https://blueprints.launchpad.net/keystone/+spec/authtoken-to-keystoneclient-repo" target="_blank">https://blueprints.launchpad.net/keystone/+spec/authtoken-to-keystoneclient-repo</a></div>
<div>and we'll review this at the keystone meeting tomorrow (<a href="http://wiki.openstack.org/Meetings/KeystoneMeeting" target="_blank">http://wiki.openstack.org/Meetings/KeystoneMeeting</a>) </div>
<div><br>
</div>
<div>-joe</div>
<div><br>
<div><br>
<div>
<div>On Sep 24, 2012, at 3:27 AM, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>>
wrote:</div>
<blockquote type="cite">
<div class="gmail_quote">On Mon, Sep 24, 2012 at 6:13 AM,
Alan Pevec <span dir="ltr"><<a href="mailto:apevec@gmail.com" target="_blank">apevec@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Mon, Sep 24, 2012 at 10:45 AM,
Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>>
wrote:<br>
> Brian Waldon wrote:<br>
>> 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?<br>
><br>
> Distributions can solve this by creating
multiple binary packages from<br>
> the same source package,<br>
<br>
</div>
I did that in Fedora for Essex, but it broke post
folsom-2 due to new<br>
intra-keystone dependencies in auth-token middleware:<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=844508" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=844508</a><br>
<br>
There's also an issue with python subpackages sharing
python namespace<br>
- who owns overlapping __init__.py ?<br>
</blockquote>
<div><br>
</div>
<div>One common way to solve that is by using a
namespace package at the top level.</div>
<div><br>
</div>
<div>Doug</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Best would be if auth-token is moved out of
keystone.middleware, there<br>
are stuff imported[1] not required by auth-token.<br>
<br>
Alan<br>
<br>
<br>
[1] <a href="https://github.com/openstack/keystone/blob/master/keystone/middleware/__init__.py#L17" target="_blank">https://github.com/openstack/keystone/blob/master/keystone/middleware/__init__.py#L17</a><br>
<div>
<div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>