Open Stack

The keystone api has had "regions" as part of the api for a long time I think. This would imply the one keystone, multiple regions definition.

Thanks,
Kevin
________________________________________
From: Geoff Arnold [geoff at geoffarnold.com]
Sent: Thursday, May 14, 2015 11:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [horizon][keystone][heat] Are      "AVAILABLE_REGIONS" and multi-region service catalog mutually   exclusive?

That’s interesting, because I wasn’t aware that “cloud” was part of the formal OpenStack taxonomy. Historically, we defined a region as a set of endpoints, supplied by an instance of Keystone.  You seem to be saying that a cloud is a collection of regions configured in the same Keystone. [citation needed]

Puzzled.

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