Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Thursday, January 02, 2014 11:14 AM
> To: openstack at lists.openstack.org
> Subject: Re: [Openstack] Fwd: [openstack] [keystone] [horizon] regions
> setup
> 
> On 01/02/2014 12:32 PM, Xu (Simon) Chen wrote:
> > A few questions..
> >
> > First, I am a little confused by this post:
> > http://docs.openstack.org/trunk/openstack-
> ops/content/segregate_cloud.html
> >
> > On the one hand, it says different regions should have no interactions
> > among them. On the other hand, it says keystone should be shared across
> > regions. I can see that sharing credentials is useful, but replicating
> > things like tokens across region seems to be a hassle to deal with - I
> > don't want to replicate the tokens that are specific to regions via WAN..
> >
> > Second, I am confused about Horizon's multi-region support. There are
> > two ways of informing a horizon instance about multiple regions. One way
> > is to configure the AVAILABLE_REGIONS variable in local_settings.py,
> > where I can put keystone endpoints associated to different regions. Then
> > something would show up in the top right corner of horizon, that I can
> > switch to a different region, log in, and it works. The second way is to
> > configure the endpoints of another region in the keystone instance local
> > to horizon. Then, a drop down list would show up on the left side of the
> > page, right beneath the list of projects. This however doesn't work,
> > since the openstack_auth package seems to be performing a simple
> > redirect assuming the same token would work across regions (my two
> > regions have completely separate keystone deployments.)
> >
> > Any ideas on the best practice here?
> 
> Hello there, Simon! :) Happy New Year!
> 
> My best advice to you would be to share identity/role/group information
> across regions (just so your users don't have to deal with separate
> creds in each region), but use the memcached token backend in each
> region's Keystone service. That way, you get the advantage of shared
> credentials but get decent token performance. As you point out,
> replicating tokens across the WAN is deadly for performance, as just a
> small number of users can quickly swamp the replicated database traffic
> from millions of tokens created and replicated.
> 
> I have no played with the AVAILABLE_REGIONS thing in Horizon yet, as I
> was under the impression that it relied on shared-region tokens
> (otherwise, users would have to grab a different token when doing things
> in different regions..)
> 
> Our users so far have not complained about simply going to the Horizon
> dashboard of the particular region they are working with, but I
> understand from Ryan Lane and others that that isn't a great user story!
> 
> All the best,
> -jay
> 

AVAILABLE_REGIONS allows login into different keystone instances, separate user/credentials.  This is different than the regions returned in the keystone service catalog which subdivide service regions for the same keystone instance.  The dropdown selector on the left-hand side of the page allows management of the latter.

If you are trying to manage separate keystone environments from the same Horizon, AVAILABLE_REGIONS should contain entries for all the keystone endpoints you want to manage.

David