I think ideally auth_token would be re-written to depend on keystoneclient, but I wouldn't intuitively look for WSGI middleware in a python client library. I'd prefer either openstack-common or a whole new package.<br clear="all">
<div><br></div>-Dolph<br>
<br><br><div class="gmail_quote">On Tue, Sep 11, 2012 at 1:42 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@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 class="im">On Tue, 2012-09-11 at 12:20 -0400, Adam Young wrote:<br>
> I think that we can get away with the current set up for auth_token<br>
> middleware  (shipping it inside Keystone but deploying it as a stand<br>
> alone file) if we move its dependencies to openstack common.  Those<br>
> dependencies are:<br>
<br>
</div>Thinking about this some more ...<br>
<br>
The auth_token middleware is a client for part of keystone's API.<br>
<br>
It could be part of keystoneclient, or another library.<br>
<br>
If it moves to openstack-commmon, it would eventually end up being<br>
published as e.g. oslo-auth after going through an API stabilization<br>
period (aka "incubation")<br>
<br>
Do we gain anything from going this route? Could we not just publish a<br>
keystone-authclient library containing the middleware?<br>
<br>
Cheers,<br>
Mark.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>