Open Stack

Thanks David..

So, I am actually curious about what Jay was suggesting.. is there a way to
have multiple separate keystone instances, but shared tokens?


On Thu, Jan 2, 2014 at 7:03 PM, Lyle, David <david.lyle at hp.com> wrote:

>
> > -----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
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140102/2380f753/attachment.html>