<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1<div class=""><br class=""></div><div class="">A wiki page laying out a mutually agreeable taxonomy seems like a good starting point.</div><div class=""><br class=""></div><div class="">Geoff</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 14, 2015, at 7:47 AM, Anne Gentle <<a href="mailto:annegentle@justwriteclick.com" class="">annegentle@justwriteclick.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold <span dir="ltr" class=""><<a href="mailto:geoff@geoffarnold.com" target="_blank" class="">geoff@geoffarnold.com</a>></span> wrote:<br class=""><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"><div style="word-wrap:break-word" class="">+1<div class=""><br class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">We have a cross-project session and spec started about the service catalog:</div><div class=""><br class=""></div><div class=""><a href="https://review.openstack.org/#/c/181393/" class="">https://review.openstack.org/#/c/181393/</a><br class=""></div><div class=""><br class=""></div><div class=""><a href="http://sched.co/3BL3" class="">http://sched.co/3BL3</a><br class=""></div><div class=""><br class=""></div><div class="">I hope more than a wiki page comes of it. :)</div><div class="">Anne</div><div class=""> </div><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"><div style="word-wrap:break-word" class=""><div class=""><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Geoff</div></font></span><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On May 13, 2015, at 9:49 PM, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank" class="">morgan.fainberg@gmail.com</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div dir="auto" class=""><div class=""><br class=""></div><div class=""><br class="">On May 13, 2015, at 21:34, David Lyle <<a href="mailto:dklyle0@gmail.com" target="_blank" class="">dklyle0@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <span dir="ltr" class=""><<a href="mailto:mgagne@iweb.com" target="_blank" class="">mgagne@iweb.com</a>></span> wrote:<br class=""><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 class="">
your "region" which is in fact "your keystone endpoint".<br class="">
<br class="">
Once logged in, you get a new dropdown at the top right to switch<br class="">
between the "keystone endpoints". This means you can configure an<br class="">
Horizon installation to login to multiple independent OpenStack<br class="">
installations.<br class="">
<br class="">
So I don't fully understand what "enhancing the multi-region support in<br class="">
Keystone" would mean. Would you be able to configure Horizon to login to<br class="">
multiple independent OpenStack installations?<br class="">
<br class="">
Mathieu<br class="">
<span class=""><br class="">
On 2015-05-13 5:06 PM, Geoff Arnold wrote:<br class="">
> Further digging suggests that we might consider deprecating<br class="">
> AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in<br class="">
> Keystone. It wouldn’t take a lot; the main points:<br class="">
><br class="">
</span>> * Implement the Regions API discussed back in the Havana time period<br class="">
<span class="">> - <a href="https://etherpad.openstack.org/p/havana-availability-zone-and-region-management" target="_blank" class="">https://etherpad.openstack.org/p/havana-availability-zone-and-region-management</a> -<br class="">
> but with full CRUD<br class="">
</span>> * Enhance the Endpoints API to allow filtering by region<br class="">
<span class="">><br class="">
> Supporting two different multi region models is problematic if we’re<br class="">
> serious about things like multi-region Heat.<br class="">
><br class="">
> Thoughts?<br class="">
><br class="">
> Geoff<br class="">
><br class="">
>> On May 13, 2015, at 12:01 PM, Geoff Arnold <<a href="mailto:geoff@GEOFFARNOLD.COM" target="_blank" class="">geoff@GEOFFARNOLD.COM</a><br class="">
</span><div class=""><div class="">>> <mailto:<a href="mailto:geoff@GEOFFARNOLD.COM" target="_blank" class="">geoff@GEOFFARNOLD.COM</a>>> wrote:<br class="">
>><br class="">
>> I’m looking at implementing dynamically-configured multi-region<br class="">
>> support for service federation, and the prior art on multi-region<br class="">
>> support in Horizon is pretty sketchy. This thread:<br class="">
>> <a href="http://lists.openstack.org/pipermail/openstack/2014-January/004372.html" target="_blank" class="">http://lists.openstack.org/pipermail/openstack/2014-January/004372.html</a><br class="">
>> is the only real discussion I’ve found, and it’s pretty inconclusive.<br class="">
>><br class="">
>> More precisely, if I configure a single Horizon with AVAILABLE_REGIONS<br class="">
>> pointing at two different Keystones with region names “X” and “Y", and<br class="">
>> each of those Keystones returns a service catalog with multiple<br class="">
>> regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s<br class="">
>> Horizon going to do? Or rather, what’s it expected to do?<br class="">
>><br class="">
>> Yes, I’m being lazy: I could actually configure this to see what<br class="">
>> happens, but hopefully it was considered during the design.<br class="">
>><br class="">
>> Geoff<br class="">
>><br class="">
>> PS I’ve added Heat to the subject, because from a quick read of<br class="">
>> <a href="https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat" target="_blank" class="">https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat</a><br class="">
>> it looks as if Heat won’t support the AVAILABLE_REGIONS model. That<br class="">
>> seems like an unfortunate disconnect.<br class="">
>><br class="">
>><br class="">
>><br class=""><span style="color:rgb(34,34,34)" class=""></span></div></div></blockquote><div class=""> </div><div class="">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 class=""><br class=""></div><div class="">What's really unclear to me is what you are intending to ask.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></div></div></div></div></blockquote><br class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">--Morgan</div></div></div></div><span class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></span></div></blockquote></div><br class=""></div></div></div><br class="">__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Anne Gentle<br class=""><a href="mailto:annegentle@justwriteclick.com" target="_blank" class="">annegentle@justwriteclick.com</a></div>
</div></div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></body></html>