[openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Matt Fischer matt at mattfischer.com
Thu Jul 9 01:02:07 UTC 2015


Is it really worth it to change the name? I agree the old name is somewhat
confusing but the new name is not perfectly clear either and will still
require a several line comment to explain what it's trying to do. What
could simply be done now is to improve the existing comment in the conf
file as well as the docs. This eliminates everyone downstream from you
having to change things (puppet/chef/ansible for example). The bike shed
really just needs touch-up paint here.

On Wed, Jul 8, 2015 at 6:47 PM, David Lyle <dklyle0 at gmail.com> wrote:

> I have no issue changing the name of AVAILABLE_REGIONS to
> AVAILABLE_KEYSTONE_ENDPOINTS, however, the old setting will need to go
> through a deprecation cycle as this is a fundamental setting in Horizon.
>
> David
>
> On Wed, Jul 8, 2015 at 8:07 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>
>> Got it, thanks for the excellent explanation, Timur! Yeah, I think
>> renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution.
>>
>> Best,
>> -jay
>>
>> On 07/08/2015 09:53 AM, Timur Sufiev wrote:
>>
>>> Hi, Jay!
>>>
>>> As Doug said, Horizon regions are just different Keystone endpoints that
>>> Horizon could use to authorize against (and retrieve the whole catalog
>>> from any of them afterwards).
>>>
>>> Another example of how complicated things could be: imagine that Horizon
>>> config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
>>> http://keystone.europe and http://keystone.asia, each of them hosting a
>>> different catalog with service endpoint pointing to Europe/Asia located
>>> services. For European Keystone all Europe-based services are marked as
>>> 'RegionOne', for Asian Keystone all its Asia-based services are marked
>>> as 'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo'
>>> region, for European Keystone the Asian services are marked so, for
>>> Asian Keystone the opposite is true. One of customers did roughly the
>>> same thing (with both Keystones using common LDAP backend), and
>>> understanding what exactly in Horizon didn't work well was a puzzling
>>> experience.
>>>
>>> On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes <jaypipes at gmail.com
>>> <mailto:jaypipes at gmail.com>> wrote:
>>>
>>>     On 07/08/2015 08:50 AM, Timur Sufiev wrote:
>>>      > Hello, folks!
>>>      >
>>>      > Somehow it happened that we have 2 different kinds of regions: the
>>>      > service regions inside Keystone catalog and AVAILABLE_REGIONS
>>> setting
>>>      > inside Horizon, yet use the same name 'regions' for both of them.
>>>     That
>>>      > creates a lot of confusion when solving some region-related
>>> issues at
>>>      > the Horizon/Keystone junction, even explaining what is exactly
>>> being
>>>      > broken poses a serious challenge when our common language has
>>>     such a flaw!
>>>      >
>>>      > I propose to invent 2 distinct terms for these entities, so at
>>>     least we
>>>      > won't be terminologically challenged when fixing the related bugs.
>>>
>>>     Hi!
>>>
>>>     I understand what the Keystone region represents: a simple,
>>>     non-geographically-connotated division of the entire OpenStack
>>>     deployment.
>>>
>>>     Unfortunately, I don't know what the Horizon regions represent. Could
>>>     you explain?
>>>
>>>     Best,
>>>     -jay
>>>
>>>
>>> __________________________________________________________________________
>>>     OpenStack Development Mailing List (not for usage questions)
>>>     Unsubscribe:
>>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>     <
>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150708/d4727e36/attachment-0001.html>


More information about the OpenStack-dev mailing list