On Thursday, May 14, 2015, Anne Gentle <[email protected]> wrote:
> > > On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 > > I, for one, am already planning on being there :) > >> Geoff >> >> On May 13, 2015, at 9:49 PM, Morgan Fainberg <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >> >> >> On May 13, 2015, at 21:34, David Lyle <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >> >> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> >> <mailto:[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>>> 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: [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> ?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
