[openstack-dev] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers?

Kai Qiang Wu wkqwu at cn.ibm.com
Fri Mar 4 05:05:22 UTC 2016


Hi Dolph,
It seems use one configuration could simply like below:

nova.conf:

**********
client_region_name = RegionOne


All clients would use that region instead of create many different
section/properties(what nova do now) for that.



But I'd like to hear what's nova/keystone developers option for that. Why
we design like that ? :)




Thanks

Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强  Kennan)
IBM China System and Technology Lab, Beijing

E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
         No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!



From:	Dolph Mathews <dolph.mathews at gmail.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>
Date:	04/03/2016 12:46 pm
Subject:	Re: [openstack-dev] [keystone][nova] Many same "region_name"
            configuration really meaingful for Multi-region customers?



Unless someone on the operations side wants to speak up and defend
cross-region nova-cinder or nova-neutron interactions as being a legitimate
use case, I'd be in favor of a single region identifier.

However, both of these configuration blocks should ultimately be used to
configure keystoneauth, so I would be in favor of whatever solution
simplifies configuration for keystoneauth.

On Tue, Mar 1, 2016 at 10:01 PM, Kai Qiang Wu <wkqwu at cn.ibm.com> wrote:
  Hi All,


  Right now, we found that nova.conf have many places for region_name
  configuration. Check below:

  nova.conf

  *******
  [cinder]
  os_region_name = ***

  [neutron]
  region_name= ***



  *******


  From some mult-region environments observation, those two regions would
  always config same value.
  Question 1: Does nova support config different regions in nova.conf ?
  Like below

  [cinder]

  os_region_name = RegionOne

  [neutron]
  region_name= RegionTwo


  From Keystone point, I suspect those regions can access from each other.


  Question 2: If all need to config with same value, why we not use single
  region_name in nova.conf ? (instead of create many region_name in same
  file )

  Is it just for code maintenance or else consideration ?



  Could nova and keystone community members help this question ?


  Thanks


  Best Wishes,
  --------------------------------------------------------------------------------

  Kai Qiang Wu (吴开强 Kennan)
  IBM China System and Technology Lab, Beijing

  E-mail: wkqwu at cn.ibm.com
  Tel: 86-10-82451647
  Address: Building 28(Ring Building), ZhongGuanCun Software Park,
  No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
  --------------------------------------------------------------------------------

  Follow your heart. You are miracle!

  __________________________________________________________________________

  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160304/d4a91d4d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160304/d4a91d4d/attachment.gif>


More information about the OpenStack-dev mailing list