Open Stack

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.fainberg at gmail.com <mailto:morgan.fainberg at gmail.com>> wrote:
>>
>>
>>
>> On May 13, 2015, at 21:34, David Lyle <dklyle0 at gmail.com
>> <mailto:dklyle0 at gmail.com>> wrote:
>>
>>>
>>> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <mgagne at iweb.com
>>> <mailto: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>
>>>     >> <mailto: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
>> <mailto: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
>