[openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them
Timur Sufiev
tsufiev at mirantis.com
Thu Sep 10 10:57:27 UTC 2015
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 <drfish at 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 at IBMUS wrote on 07/08/2015 01:05:53 PM:
>
> > From: Thai Q Tran/Silicon Valley/IBM at IBMUS
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > <openstack-dev at 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 <jaypipes at gmail.com> wrote: -----
> > To: openstack-dev at lists.openstack.org
> > From: Jay Pipes <jaypipes at 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 <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-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-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/20150910/403b1548/attachment.html>
More information about the OpenStack-dev
mailing list