Open Stack

Anne Gentle <annegentle at justwriteclick.com> wrote on 05/14/2015 09:47:25
AM:

> From: Anne Gentle <annegentle at justwriteclick.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 05/14/2015 10:08 AM
> Subject: Re: [openstack-dev] [horizon][keystone][heat] Are
> "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?
>
> On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold <geoff at geoffarnold.com>
wrote:
> +1
>
> There seems to be a significant disconnect between Heat, Horizon and
> Keystone on the subject of multi-region configurations, and the
> documentation isn’t helpful. At the very least, it would be useful
> if discussions at the summit could result in a decent Wiki page on
> the subject.
>
> We have a cross-project session and spec started about the service
catalog:
>
> https://review.openstack.org/#/c/181393/
>
> http://sched.co/3BL3
>
> I hope more than a wiki page comes of it. :)
> Anne
>
>
> Geoff
>
> On May 13, 2015, at 9:49 PM, Morgan Fainberg <morgan.fainberg at gmail.com
> > wrote:
>
>
> On May 13, 2015, at 21:34, David Lyle <dklyle0 at gmail.com> wrote:

>
> 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.
>
> I'd like to quickly go on record and say that a token store sync
> like this is not recommended. It is possible to work around this in
> Kilo with some limited data sync (resource, assignment) and the use
> of Fernet tokens. However, as you introduce higher latencies and WAN
> transit this type of syncing becomes more and more prone to error.
>
> It would be possible to make DOA multi keystone aware, but before we
> dive too far into this I'd like to get a clear view of what exactly
> the use case (and goal is); let's do this at the summit (since it is
> happening soon). Having a clear view will make this easier to
> determine if AVAILABLE_REGIONS or another mechanism is/will be
> better suited. We can then summarize and report the results back to
> this thread to keep everyone apprised of the direction.
>
> --Morgan
>
__________________________________________________________________________
> 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

>

>
> --
> Anne Gentle
> annegentle at justwriteclick.com
>
__________________________________________________________________________
> 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

I have some WIP patches related to Keystone 2 Keystone federation that are
ultimately about making Horizon multi keystone aware:

https://review.openstack.org/#/c/159910/  WIP: K2K federation
https://review.openstack.org/#/c/160851/  WIP: Sample keystone client usage
for k2k federation
https://review.openstack.org/#/c/172155/  Add Keystone2KeystoneAuthPlugin
for K2K federation
https://blueprints.launchpad.net/horizon/+spec/k2k-federation

The main use case I have in mind is hybrid environments where a user might
belong to the admin group in one keystone, but not in the other.

I have not yet dealt with Horizon's existing "AVAILABLE_REGIONS" setting.
My approach doesn't explicitly expose the fact that there are multiple
keystones (though I suspect that a complete treatment of the environment is
going to require that).

Doug