Open Stack

On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold <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


>
> Geoff
>
> On May 13, 2015, at 9:49 PM, Morgan Fainberg <morgan.fainberg at gmail.com>
> wrote:
>
>
>
> On May 13, 2015, at 21:34, David Lyle <dklyle0 at gmail.com> wrote:
>
>
> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <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>> 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?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
>
>


-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150514/e0e022a1/attachment.html>