+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.
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 > <mailto:dkly...@gmail.com>> wrote: > >> >> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <mga...@iweb.com >> <mailto: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 >> > >> > <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> >> >> <mailto: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 >> >> <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 >> >> >> >> <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
