Open Stack

On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <mgagne at iweb.com> wrote:

> When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
> your "region" which is in fact "your keystone endpoint".
>
> Once logged in, you get a new dropdown at the top right to switch
> between the "keystone endpoints". This means you can configure an
> Horizon installation to login to multiple independent OpenStack
> installations.
>
> So I don't fully understand what "enhancing the multi-region support in
> Keystone" would mean. Would you be able to configure Horizon to login to
> multiple independent OpenStack installations?
>
> Mathieu
>
> On 2015-05-13 5:06 PM, Geoff Arnold wrote:
> > Further digging suggests that we might consider deprecating
> > AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
> > Keystone. It wouldn’t take a lot; the main points:
> >
> >   * Implement the Regions API discussed back in the Havana time period
> >     -
> https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
> -
> >     but with full CRUD
> >   * Enhance the Endpoints API to allow filtering by region
> >
> > Supporting two different multi region models is problematic if we’re
> > serious about things like multi-region Heat.
> >
> > Thoughts?
> >
> > Geoff
> >
> >> On May 13, 2015, at 12:01 PM, Geoff Arnold <geoff at GEOFFARNOLD.COM
> >> <mailto:geoff at GEOFFARNOLD.COM>> wrote:
> >>
> >> I’m looking at implementing dynamically-configured multi-region
> >> support for service federation, and the prior art on multi-region
> >> support in Horizon is pretty sketchy. This thread:
> >> http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
> >> is the only real discussion I’ve found, and it’s pretty inconclusive.
> >>
> >> More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
> >> pointing at two different Keystones with region names “X” and “Y", and
> >> each of those Keystones returns a service catalog with multiple
> >> regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
> >> Horizon going to do? Or rather, what’s it expected to do?
> >>
> >> Yes, I’m being lazy: I could actually configure this to see what
> >> happens, but hopefully it was considered during the design.
> >>
> >> Geoff
> >>
> >> PS I’ve added Heat to the subject, because from a quick read of
> >>
> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
> >> it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
> >> seems like an unfortunate disconnect.
> >>
> >>
> >>
>

Horizon only supports authenticating to one keystone endpoint at a time,
specifically to one of the entries in AVAILABLE_REGIONS as defined in
settings.py. Once you have an authenticated session in Horizon, the region
selection support is merely for filtering between regions registered with
the keystone endpoint you authenticated to, where the list of regions is
determined by parsing the service catalog returned to you with your token.

What's really unclear to me is what you are intending to ask.

AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be
backed by a different IdP per endpoint and thus not share a token store.
Or, they can just be keystone endpoints that are geographically different
but backed by the same IdP, which may or may not share a token store. The
funny thing is, for Horizon, it doesn't matter. They are all supported.
But as one keystone endpoint may not know about another, unless nested,
this has to be done with settings as it's not typically discoverable.

If you are asking about token sharing between keystones which the thread
you linked seems to indicate. Then yes, you can have a synced token store.
But that is an exercise left to the operator.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150513/837175b1/attachment.html>