[keystone][service-catalog] Region "*" for identity in service catalog
Mohammed Naser
mnaser at vexxhost.com
Mon Feb 18 18:40:49 UTC 2019
Hi Artem,
You bring up a great point. While I don't have the answer, I think
this is something that we share as an operator in terms of finding the
solution for. I'd be happy to work together to bring up the ideal
solution for this.
Thanks,
Mohammed
On Fri, Feb 15, 2019 at 4:45 AM Artem Goncharov
<artem.goncharov at gmail.com> wrote:
>
> Hi all,
>
> In a public cloud I am using there is currently one region, but should be multiple in future. Endpoint for each service has a region set. However the only exception is identity, which has an empty region (actually "*"). If I do not specify region_name during connection (with diverse tools) everything works fine. Some "admin" operations, however, really require region to be set. But if I set in (i.e. in clouds.yaml) I can't connect to cloud, since identity in this region has no explicit endpoint (keystoneauth1 is not ok with that, gophercloud as well)
>
> I was not able to find any requirements/conventions, how such setup should be really treated. On https://wiki.openstack.org/wiki/API_Special_Interest_Group/Current_Design/Service_Catalog there are service catalogs for diverse clouds, and in case where a cloud has multiple region, there are multiple entries for keystone pointing to the same endpoint. Basically each time there is region properly set.
>
> In Keystone.v2 region was mandatory, but in v3 it is not anymore (https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/endpoint.html#endpoint-create). I guess in a normal way you would not be even able to configure region "*", but it was somehow done.
>
> While there is only one region the problem is not that big, but as soon as second region is added it becomes problem. Does anyone knows if that is an "allowed" setup (but then tools should be adapted to treat it properly), or this is not an "allowed" configuration (in this case I would like to see some docs to refer properly). I would personally prefer second way of fixing catalog to avoid fixes in diverse tools, but I really need a weightful reference for that.
>
>
> Thanks a lot in advance,
> Artem
--
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com
More information about the openstack-discuss
mailing list