Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-15 Thread Douglas Fish 

Anne Gentle  wrote on 05/14/2015 09:47:25
AM:

> From: Anne Gentle 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 05/14/2015 10:08 AM
> Subject: Re: [openstack-dev] [horizon][keystone][heat] Are
> "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?
>
> On Thu, May 14, 2015 at 9:39 AM, 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.
>
> 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  > wrote:
>
>
> On May 13, 2015, at 21:34, David Lyle  wrote:

>
> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné  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  >> <mailto:ge...@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 t

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Zane Bitter 

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  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
mailto:morgan.fainb...@gmail.com>> wrote:



On May 13, 2015, at 21:34, David Lyle mailto:dkly...@gmail.com>> wrote:



On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mailto:mga...@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 mailto:ge...@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.opensta

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Geoff Arnold 
If we don’t want to deprecate AVAILABLE_REGIONS, we certainly need to clean up 
the ambiguity. And to be honest, the existing documentation for both 
"multi-region” schemes (AVAILABLE_REGIONS and Keystone based) is completely 
inadequate. 

Geoff

> On May 14, 2015, at 1:13 PM, Mathieu Gagné  wrote:
> 
> On 2015-05-14 12:34 AM, David Lyle wrote:
>> 
>> 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.
> 
> I'm asking to NOT remove the feature provided by AVAILABLE_REGIONS which
> is what you described: support for multiple keystone endpoint (or
> OpenStack installations) in one Horizon installation.
> 
>> 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'm not suggesting token sharing. I'm merely trying to explain that
> AVAILABLE_REGIONS answers a different need than "multi-regions in the
> same keystone endpoint" which Horizon already supports fine.
> 
> Those are 2 features answering different needs and "AVAILABLE_REGIONS"
> shouldn't be removed as suggested previously: "we might consider
> deprecating AVAILABLE_REGIONS in Horizon".
> 
> -- 
> Mathieu
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Mathieu Gagné 
On 2015-05-14 12:34 AM, David Lyle wrote:
>  
> 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.

I'm asking to NOT remove the feature provided by AVAILABLE_REGIONS which
is what you described: support for multiple keystone endpoint (or
OpenStack installations) in one Horizon installation.

> 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'm not suggesting token sharing. I'm merely trying to explain that
AVAILABLE_REGIONS answers a different need than "multi-regions in the
same keystone endpoint" which Horizon already supports fine.

Those are 2 features answering different needs and "AVAILABLE_REGIONS"
shouldn't be removed as suggested previously: "we might consider
deprecating AVAILABLE_REGIONS in Horizon".

-- 
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Fox, Kevin M 
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 [ge...@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  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
>>> mailto:morgan.fainb...@gmail.com>> wrote:
>>>
>>>
>>>
>>> On May 13, 2015, at 21:34, David Lyle >> <mailto:dkly...@gmail.com>> wrote:
>>>
>>>>
>>>> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné >>> <mailto:mga...@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 >>> <mailto:ge...@geoffarnold.com>
>>>>>> <mailto:ge...@geoffarnold.com <mailto:ge...@geoffarnold.com>>>
>>>>wrote:
>>>>>>
>>>>>> I’m looking at implementing dynamically-configured multi-region
>>>>>> support for service federation, and the prior

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Geoff Arnold 
+1

A wiki page laying out a mutually agreeable taxonomy seems like a good starting 
point.

Geoff

> On May 14, 2015, at 7:47 AM, Anne Gentle  
> wrote:
> 
> 
> 
> On Thu, May 14, 2015 at 9:39 AM, 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.
> 
> 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 > > wrote:
>> 
>> 
>> 
>> On May 13, 2015, at 21:34, David Lyle > > wrote:
>> 
>>> 
>>> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné >> > 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 >> >> 
>>> >> >> 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

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Geoff Arnold 
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  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
>>> mailto:morgan.fainb...@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>> On May 13, 2015, at 21:34, David Lyle >> > wrote:
>>> 
 
 On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné >>> > 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 >>> 
>> >>
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

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Morgan Fainberg 
On Thursday, May 14, 2015, Anne Gentle 
wrote:

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

I, for one, am already planning on being there :)


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

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Zane Bitter 

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
mailto:morgan.fainb...@gmail.com>> wrote:



On May 13, 2015, at 21:34, David Lyle mailto:dkly...@gmail.com>> wrote:



On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mailto:mga...@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 mailto:ge...@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

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Anne Gentle 
On Thu, May 14, 2015 at 9:39 AM, 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.
>

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 
> wrote:
>
>
>
> On May 13, 2015, at 21:34, David Lyle  wrote:
>
>
> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné  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 > >> > 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 c

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-14 Thread Geoff Arnold 
+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.

Geoff

> On May 13, 2015, at 9:49 PM, Morgan Fainberg  
> wrote:
> 
> 
> 
> On May 13, 2015, at 21:34, David Lyle  > wrote:
> 
>> 
>> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné > > 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 > >> 
>> >> >> 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 tra

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-13 Thread Morgan Fainberg 


> On May 13, 2015, at 21:34, David Lyle  wrote:
> 
> 
>> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné  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 > >> > 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/ma

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-13 Thread David Lyle 
On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné  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  >> > 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.

David
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-13 Thread Mathieu Gagné 
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 > > 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.
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-13 Thread Geoff Arnold 
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  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.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

2015-05-13 Thread Geoff Arnold 
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.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev