Is there an API that needs to distinguish between "public service" and "public administrative" interfaces? (in addition to "internal service" and "internal administrative")<br><div class="gmail_extra">
<br clear="all"><div><div><br></div>-Dolph</div><br>
<br><br><div class="gmail_quote">On Thu, Dec 13, 2012 at 6:50 PM, Mark Washenberger <span dir="ltr"><<a href="mailto:mark.washenberger@markwash.net" target="_blank">mark.washenberger@markwash.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I guess my question then becomes, should we support an external/public<br>
admin use case?<br>
<br>
Thanks!<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Dec 13, 2012 at 1:05 PM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
> I think it's meant to be implied that the "admin" endpoint is also internal.<br>
><br>
> auth_token should certainly consume the service catalog (via keystoneclient,<br>
> ideally). Moving auth_token into keystoneclient itself was a first step in<br>
> that direction, IMO.<br>
><br>
><br>
> On Thursday, December 13, 2012, Mark Washenberger wrote:<br>
>><br>
>> 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="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>
><br>
><br>
><br>
> --<br>
><br>
> -Dolph<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>
><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></div>