Open Stack

Hi ,

Please let me know if we can go ahead and create cells.
I have the API (parent) and childcell1 and childcell2. I followed open
stack doc.

I have the rabbit settings and nova-manage commands on parent it works
fine. On the child cells it gives
Operational error insert cells error. Any thoughts, help would be
appreciated.

The regions write up is very helpful.

Regards,
Raghavendra Lad


On Sun, Nov 30, 2014 at 3:57 AM, Joe Topjian <joe at topjian.net> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20150225/a3b855ad/attachment.html>