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

Geoff Arnold geoff at geoffarnold.com
Thu May 14 21:16:51 UTC 2015


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é <mgagne at iweb.com> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list