Open Stack

On 14/05/15 14:41, Geoff Arnold wrote:
> That’s interesting, because I wasn’t aware that “cloud” was part of the formal OpenStack taxonomy.

Um, OK. AWS, Rackspace and Helion are all different clouds, even though 
the last two both run OpenStack. Do we really need a formal taxonomy for 
that?

Likewise, if you install OpenStack twice, you get two different clouds. 
Each of which may or may not be split into multiple regions.

> Historically, we defined a region as a set of endpoints, supplied by an instance of Keystone.

Right.

> You seem to be saying that a cloud is a collection of regions configured in the same Keystone.

Yes, that's what I'm saying. How is that different?

> [citation needed]

Seriously, this is not nearly as complicated as you are making out.

> Puzzled.

Two regions that don't appear in the same Keystone catalog are not part 
of the same cloud. Horizon offers support for dealing with multiple 
regions within a single cloud. It also offers an option to switch 
between multiple different clouds using an option unfortunately called 
AVAILABLE_REGIONS, which is a total misnomer.

- ZB

>
> Geoff
>
>> On May 14, 2015, at 7:56 AM, Zane Bitter <zbitter at redhat.com> wrote:
>>
>> 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.fainberg at gmail.com <mailto:morgan.fainberg at gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On May 13, 2015, at 21:34, David Lyle <dklyle0 at gmail.com
>>>> <mailto:dklyle0 at gmail.com>> wrote:
>>>>
>>>>>
>>>>> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné <mgagne at iweb.com
>>>>> <mailto: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>
>>>>>     >> <mailto: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
>>>> <mailto: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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>