<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On May 13, 2015, at 21:34, David Lyle <<a href="mailto:dklyle0@gmail.com">dklyle0@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <span dir="ltr"><<a href="mailto:mgagne@iweb.com" target="_blank">mgagne@iweb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">When using AVAILABLE_REGIONS, you get a dropdown at login time to choose<br>
your "region" which is in fact "your keystone endpoint".<br>
<br>
Once logged in, you get a new dropdown at the top right to switch<br>
between the "keystone endpoints". This means you can configure an<br>
Horizon installation to login to multiple independent OpenStack<br>
installations.<br>
<br>
So I don't fully understand what "enhancing the multi-region support in<br>
Keystone" would mean. Would you be able to configure Horizon to login to<br>
multiple independent OpenStack installations?<br>
<br>
Mathieu<br>
<span class=""><br>
On 2015-05-13 5:06 PM, Geoff Arnold wrote:<br>
> Further digging suggests that we might consider deprecating<br>
> AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in<br>
> Keystone. It wouldn’t take a lot; the main points:<br>
><br>
</span>> * Implement the Regions API discussed back in the Havana time period<br>
<span class="">> - <a href="https://etherpad.openstack.org/p/havana-availability-zone-and-region-management" target="_blank">https://etherpad.openstack.org/p/havana-availability-zone-and-region-management</a> -<br>
> but with full CRUD<br>
</span>> * Enhance the Endpoints API to allow filtering by region<br>
<span class="im">><br>
> Supporting two different multi region models is problematic if we’re<br>
> serious about things like multi-region Heat.<br>
><br>
> Thoughts?<br>
><br>
> Geoff<br>
><br>
>> On May 13, 2015, at 12:01 PM, Geoff Arnold <<a href="mailto:geoff@GEOFFARNOLD.COM">geoff@GEOFFARNOLD.COM</a><br>
</span><div class=""><div class="h5">>> <mailto:<a href="mailto:geoff@GEOFFARNOLD.COM">geoff@GEOFFARNOLD.COM</a>>> wrote:<br>
>><br>
>> I’m looking at implementing dynamically-configured multi-region<br>
>> support for service federation, and the prior art on multi-region<br>
>> support in Horizon is pretty sketchy. This thread:<br>
>> <a href="http://lists.openstack.org/pipermail/openstack/2014-January/004372.html" target="_blank">http://lists.openstack.org/pipermail/openstack/2014-January/004372.html</a><br>
>> is the only real discussion I’ve found, and it’s pretty inconclusive.<br>
>><br>
>> More precisely, if I configure a single Horizon with AVAILABLE_REGIONS<br>
>> pointing at two different Keystones with region names “X” and “Y", and<br>
>> each of those Keystones returns a service catalog with multiple<br>
>> regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s<br>
>> Horizon going to do? Or rather, what’s it expected to do?<br>
>><br>
>> Yes, I’m being lazy: I could actually configure this to see what<br>
>> happens, but hopefully it was considered during the design.<br>
>><br>
>> Geoff<br>
>><br>
>> PS I’ve added Heat to the subject, because from a quick read of<br>
>> <a href="https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat" target="_blank">https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat</a><br>
>> it looks as if Heat won’t support the AVAILABLE_REGIONS model. That<br>
>> seems like an unfortunate disconnect.<br>
>><br>
>><br>
>><br><span style="color:rgb(34,34,34)"></span></div></div></blockquote><div> </div><div>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. </div><div><br></div><div>What's really unclear to me is what you are intending to ask.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div></div></div></div></blockquote><br><div>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. </div><div><br></div><div>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. </div><div><br></div><div>--Morgan</div></body></html>