The keystone api has had "regions" as part of the api for a long time I think. This would imply the one keystone, multiple regions definition.
Thanks, Kevin ________________________________________ From: Geoff Arnold [ge...@geoffarnold.com] Sent: Thursday, May 14, 2015 11:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive? That’s interesting, because I wasn’t aware that “cloud” was part of the formal OpenStack taxonomy. Historically, we defined a region as a set of endpoints, supplied by an instance of Keystone. You seem to be saying that a cloud is a collection of regions configured in the same Keystone. [citation needed] Puzzled. Geoff > On May 14, 2015, at 7:56 AM, Zane Bitter <zbit...@redhat.com> wrote: > > On 14/05/15 10:39, Geoff Arnold 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. > > The terminology I (and Heat) have always used is that regions are sets of > endpoints configured in the same Keystone. Where you have a different > Keystone auth URL that is straight up a separate cloud, no matter how you > slice it. > > The confusion here seems to be that Horizon is using the name > AVAILABLE_REGIONS to denote available Keystone auth URLS - i.e. different > clouds, not different regions at all. > > Looked at through that lens, things seem a bit easier to understand. > > Heat supports multi-region trees of stacks (i.e. you can created a nested > stack in another region). Multi-cloud support has been considered, but afaik > has not yet landed. Figuring out where to store the credentials securely is > tricky. > > cheers, > Zane. > >> Geoff >> >>> On May 13, 2015, at 9:49 PM, Morgan Fainberg >>> <morgan.fainb...@gmail.com <mailto: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 >>>> - >>>> > 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 >>>> >> 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 >>> <mailto: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 >> > > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
