I think it's meant to be implied that the "admin" endpoint is also internal.<div><br></div><div>auth_token should certainly consume the service catalog (via keystoneclient, ideally)<span></span>. Moving auth_token into keystoneclient itself was a first step in that direction, IMO.<br>
<br>On Thursday, December 13, 2012, Mark Washenberger  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi keystone folks,<br>
<br>
When I do keystone help endpoint-create, I see<br>
<br>
  --publicurl <public-url><br>
                        Public URL endpoint<br>
  --adminurl <admin-url><br>
                        Admin URL endpoint<br>
  --internalurl <internal-url><br>
                        Internal URL endpoint<br>
<br>
Is there any reason why we don't support an internal admin use case?<br>
<br>
If we did, we might be able to make the auth_token middleware use its<br>
own service catalog instead of a configured default for validating<br>
(uuid) tokens, which I would imagine could help out with some deployer<br>
migration scenarios.<br>
<br>
Any thoughts? Should I write up a brief blueprint?<br>
<br>
markwash<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', '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>
</blockquote></div><br><br>-- <br><div><br></div>-Dolph<br>