Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them
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 <drf...@us.ibm.com> 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\)" > > <openstack-dev@lists.openstack.org> > > 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 <jaypi...@gmail.com> wrote: ----- > > To: openstack-dev@lists.openstack.org > > From: Jay Pipes <jaypi...@gmail.com> > > 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 <jaypi...@gmail.com > > > <mailto:jaypi...@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-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? > > >
Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them
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\) openstack-dev@lists.openstack.org 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 jaypi...@gmail.com wrote: - To: openstack-dev@lists.openstack.org From: Jay Pipes jaypi...@gmail.com 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 jaypi...@gmail.com mailto:jaypi...@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-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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development
Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them
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 jaypi...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
