Open Stack

On Thursday, May 14, 2015, Anne Gentle <annegentle at justwriteclick.com>
wrote:

>
>
> On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold <geoff at geoffarnold.com
> <javascript:_e(%7B%7D,'cvml','geoff at geoffarnold.com');>> 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 <morgan.fainberg at gmail.com
>> <javascript:_e(%7B%7D,'cvml','morgan.fainberg at gmail.com');>> wrote:
>>
>>
>>
>> On May 13, 2015, at 21:34, David Lyle <dklyle0 at gmail.com
>> <javascript:_e(%7B%7D,'cvml','dklyle0 at gmail.com');>> wrote:
>>
>>
>> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <mgagne at iweb.com
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','geoff at GEOFFARNOLD.COM');>
>>> >> <mailto:geoff at GEOFFARNOLD.COM
>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','OpenStack-dev-request at lists.openstack.org');>
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150514/3ee1b3f3/attachment.html>