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.l...@hp.com> wrote: > > > -----Original Message----- > > From: Jay Pipes [mailto:jaypi...@gmail.com] > > Sent: Thursday, January 02, 2014 11:14 AM > > To: openstack@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@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
