Open Stack

Hello,

Regions can be a little confusing because of their ambiguity.

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:

(IMO, using the Keystone templated catalog
<https://github.com/openstack/keystone/blob/master/etc/default_catalog.templates>
makes things easier to understand)

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.

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.

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.

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).

Now here's another example:

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.

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.

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.

On the topic of sharing user, tenants, and what's easiest:

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.

Now for Horizon:

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.

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.

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.

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.

Thanks,
Joe



On Fri, Nov 28, 2014 at 10:15 PM, Chris <contact at progbau.de> wrote:

> Hi,
>
> what exactly is easier to use? When I use the same tenants but specify the
> different regions during the endpoint creation, is it enough?
>
> 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?
>
> Unfortunately I couldn't find any manual how to proper configure a second
> regions, just a bug report, reporting the lack of documentation :)
> https://bugs.launchpad.net/openstack-manuals/+bug/1340509
>
> Cheers
> Chris
>
> On 2014-11-28 20:54, Jay Pipes wrote:
>
>> On 11/28/2014 06:40 AM, Chris wrote:
>>
>>> Hello Robert,
>>>
>>> thx for your answer! Does we need to create new admin/service tenants
>>> for the new services in the new region or should we use the old ones?
>>>
>>
>> It's much easier to use the same ones, in my experience.
>>
>> Best,
>> -jay
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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/20141129/06ddebed/attachment.html>