Anne Gentle <annegen...@justwriteclick.com> wrote on 05/14/2015 09:47:25 AM:
> From: Anne Gentle <annegen...@justwriteclick.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 <ge...@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.fainb...@gmail.com > > wrote: > > > On May 13, 2015, at 21:34, David Lyle <dkly...@gmail.com> wrote: > > On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <mga...@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 <ge...@geoffarnold.com > >> <mailto:ge...@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-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 > > > -- > Anne Gentle > annegen...@justwriteclick.com > __________________________________________________________________________ > 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 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 __________________________________________________________________________ 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
