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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]>> 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: >>>> [email protected]?subject:unsubscribe >>>> < >>>> http://[email protected]?subject:unsubscribe> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
