[openstack-dev] [Keystone] internalAdminURL?

Mark Washenberger mark.washenberger at markwash.net
Fri Dec 14 17:10:04 UTC 2012


Oh, perhaps not? I was under the (hopefully mistaken!) impression that
keystone administration and service-level actions required use of the
admin interface. For example, tenant administration and (UUID) token
validation. I reassured myself that this was the case with some manual
tests in a devstack deployment, but please let me know if I've made
some mistake.

Thanks

On Thu, Dec 13, 2012 at 6:00 PM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> Is there an API that needs to distinguish between "public service" and
> "public administrative" interfaces? (in addition to "internal service" and
> "internal administrative")
>
>
> -Dolph
>
>
>
> On Thu, Dec 13, 2012 at 6:50 PM, Mark Washenberger
> <mark.washenberger at markwash.net> wrote:
>>
>> I guess my question then becomes, should we support an external/public
>> admin use case?
>>
>> Thanks!
>>
>> On Thu, Dec 13, 2012 at 1:05 PM, Dolph Mathews <dolph.mathews at gmail.com>
>> wrote:
>> > I think it's meant to be implied that the "admin" endpoint is also
>> > internal.
>> >
>> > auth_token should certainly consume the service catalog (via
>> > keystoneclient,
>> > ideally). Moving auth_token into keystoneclient itself was a first step
>> > in
>> > that direction, IMO.
>> >
>> >
>> > On Thursday, December 13, 2012, Mark Washenberger wrote:
>> >>
>> >> Hi keystone folks,
>> >>
>> >> When I do keystone help endpoint-create, I see
>> >>
>> >>   --publicurl <public-url>
>> >>                         Public URL endpoint
>> >>   --adminurl <admin-url>
>> >>                         Admin URL endpoint
>> >>   --internalurl <internal-url>
>> >>                         Internal URL endpoint
>> >>
>> >> Is there any reason why we don't support an internal admin use case?
>> >>
>> >> If we did, we might be able to make the auth_token middleware use its
>> >> own service catalog instead of a configured default for validating
>> >> (uuid) tokens, which I would imagine could help out with some deployer
>> >> migration scenarios.
>> >>
>> >> Any thoughts? Should I write up a brief blueprint?
>> >>
>> >> markwash
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > --
>> >
>> > -Dolph
>> >
>> > _______________________________________________
>> > 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 list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list