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
