I went forward and filed a bug for this issue (since we agreed that it should be fixed): https://bugs.launchpad.net/horizon/+bug/1494251 The code is already in gerrit (see links in bug), feel free to review.
On Fri, Jul 10, 2015 at 1:51 AM Douglas Fish <[email protected]> wrote: > I think another important question is how to represent this to the user on > the login screen. "Keystone Endpoint:" matches the setting, but seems like > a weird choice to me. Is there a better terminology to use for the label > for this on the login screen? > > I see the related selector has no label at all in the header. Maybe using > the same label there would be a good idea. > > Doug > > Thai Q Tran/Silicon Valley/IBM@IBMUS wrote on 07/08/2015 01:05:53 PM: > > > From: Thai Q Tran/Silicon Valley/IBM@IBMUS > > To: "OpenStack Development Mailing List \(not for usage questions\)" > > <[email protected]> > > Date: 07/09/2015 01:17 PM > > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds > > of 'region' entity: finding better names for them > > > > Had the same issue when I worked on the context selection menu for > > switching domain and project. I think it make sense to rename it to > > AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its > > going to affect some folks (maybe even break) until they also update > > their setting, something that would have to be done manually. > > > > -----Jay Pipes <[email protected]> wrote: ----- > > To: [email protected] > > From: Jay Pipes <[email protected]> > > Date: 07/08/2015 07:14AM > > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds > > of 'region' entity: finding better names for them > > > 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-relatedissues 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
