Open Stack

Matt,

I don't think it's a bike-shedding. The problem is not the existing name
being a bit obscure - until I hit some issues with Keystone native regions
I didn't have any troubles with it. The problem is that we have the _same_
name for different things, and no additional comments will remedy the
confusion caused by this.

On Thu, Jul 9, 2015 at 4:03 AM Matt Fischer <matt at mattfischer.com> wrote:

> 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
>>
>>
> __________________________________________________________________________
> 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/20150709/68a8e613/attachment.html>