<div dir="ltr">Hello,<div><br></div><div>Regions can be a little confusing because of their ambiguity.</div><div><br></div><div>Regions are really nothing more than a tag you give an endpoint in the Identity catalog. Depending on how you use that tag determines how regions are used in your environment. Here are a few scenarios:</div><div><br></div><div>(IMO, using the <a href="https://github.com/openstack/keystone/blob/master/etc/default_catalog.templates">Keystone templated catalog</a> makes things easier to understand)</div><div><br></div><div>Let's say you have one Identity service hosted on one server. In the catalog, you create two Identity entries that are identical (same endpoints), except one is for RegionOne and the other is for RegionTwo. You've now just created two Regions in OpenStack and these regions will share the same user database.</div><div><br></div><div>You can then proceed to add your other services to the catalog and tag them with whichever region they should be available in. Any other service that is added twice, has the same endpoints, but different region, will be the same service shared between both regions. Take the Image (glance) service for example. If you specify it twice just as you did with the Identity service, then your image catalog will be shared between regions.</div><div><br></div><div>You could very well add all services with the same endpoints twice, but in reality you now have just one region. So to effectively use regions, you need to balance what's shared and what's not depending on your use-case.</div><div><br></div><div>As an end-user, to specify the region you want to use, either set the OS_REGION_NAME environment variable for the command line tools, or choose the region in Horizon (more on this later).</div><div><br></div><div>Now here's another example:</div><div><br></div><div>Let's say you have two Identity services hosted on two different servers. One for each region. These two servers share the same Keystone MySQL database. In the catalog of each server, you specify only one set of services: the services for that region. Because the database is shared, you're still effectively sharing the same users in each region, but because the endpoints are different for the Identity service, end-users will need to specify both OS_REGION_NAME and OS_AUTH_URL on the command line.</div><div><br></div><div>There's a third example that is a hybrid of the two above examples: multiple Identity servers that each host all catalog entries for all regions. I personally have not tested this scenario yet, so I can't comment on it.</div><div><br></div><div>The reason you would consider multiple Identity servers is for high availability. If you are using regions as a way to divide your cloud into distinct physical areas (different data centres perhaps) and the data centre where the central Identity server goes offline, then users could not log into any region.</div><div><br></div><div>On the topic of sharing user, tenants, and what's easiest:</div><div><br></div><div>You could create a separate "services" tenant for each region (services_regionone, services_regiontwo), but I believe Jay was saying that it's easiest to just use the same "services" tenant across all regions. I concur. In nova.conf, glance-*.conf, cinder.conf, etc, you do not need to add any region info to the keystone auth settings. I believe a region_name setting exists, but I've never had to use it.</div><div><br></div><div>Now for Horizon:</div><div><br></div><div>Historically, Horizon did not work well when the catalog contained entries for multiple regions (another reason to use the separate server scenario described above). Fortunately that's a thing of the past.</div><div><br></div><div>Presently, if your catalog contains entries for all of your regions, you do not need to do any special configuration of Horizon. A user logs in, and once logged in, they can choose what region to work in. Even better, they will be transferred to that region without having to re-authenticate. This is a wonderful user experience.</div><div><br></div><div>If your regions are contained in multiple catalogs (perhaps because you have been using regions before Horizon fixed this :), you must specify each region in the AVAILABLE_REGIONS setting of local_settings.py. When a user first visits Horizon, they will enter their username, password, and choose a region. When they log in and want to switch regions, they choose the region from a drop-down, but will then be asked to re-authenticate.</div><div><br></div><div>This is the extent of my knowledge of Regions. I hope it helped clarify some areas. And if anyone has anything additional to add or correct, I'd love to hear as I use regions extensively.</div><div><br></div><div>Thanks,</div><div>Joe</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 28, 2014 at 10:15 PM, Chris <span dir="ltr"><<a href="mailto:contact@progbau.de" target="_blank">contact@progbau.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
what exactly is easier to use? When I use the same tenants but specify the different regions during the endpoint creation, is it enough?<br>
<br>
Second additional question, is the separation in the different regions just for the endpoints or does the "noca.conf" and other configuration files need to be changed as well?<br>
<br>
Unfortunately I couldn't find any manual how to proper configure a second regions, just a bug report, reporting the lack of documentation :) <a href="https://bugs.launchpad.net/openstack-manuals/+bug/1340509" target="_blank">https://bugs.launchpad.net/<u></u>openstack-manuals/+bug/1340509</a><br>
<br>
Cheers<br>
Chris<br>
<br>
On 2014-11-28 20:54, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/28/2014 06:40 AM, Chris wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Robert,<br>
<br>
thx for your answer! Does we need to create new admin/service tenants<br>
for the new services in the new region or should we use the old ones?<br>
</blockquote>
<br>
It's much easier to use the same ones, in my experience.<br>
<br>
Best,<br>
-jay<br>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><br>
</blockquote></div><br></div>