osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[keystone][service-catalog] Region "*" for identity in service catalog


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190215/98fe6320/attachment.html>