If there is environment variable to define the role of each node, it's good. To
support multi-region devstack gate/check job, we have to configure the localrc
for each node of different role, for example:
for the second region node, need to configure it to use the primary
node's keystone:
local sub_node=`cat /etc/nodepool/sub_nodes_private`
echo "HOST_IP=$sub_node" >>"$localrc_file"
echo "SERVICE_HOST=$HOST_IP" >>"$localrc_file"
echo "REGION_NAME=RegionTwo" >>"$localrc_file"
echo "KEYSTONE_REGION_NAME=RegionOne" >>"$localrc_file"
echo "KEYSTONE_SERVICE_HOST=$primary_node" >>"$localrc_file"
echo "KEYSTONE_AUTH_HOST=$primary_node" >>"$localrc_file"
for the primary node where the keystone service will be enabled:
echo "HOST_IP=$primary_node" >>"$localrc_file"
echo "REGION_NAME=RegionOne" >>"$localrc_file
If there is only one role environment variable, then the primary node should
always set HOST_IP to $primary_node but not the default 127.0.0.1, because the
keystone will not work well in multi-region scenario if HOST_IP is 127.0.0.1.
Best Regards
Chaoyi Huang (joehuang)
________________________________________
From: Sean M. Collins [s...@coreitpro.com]
Sent: 10 January 2017 22:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [infra][devstack-gate][all]support multi-region
gate environment
joehuang wrote:
> In multi-region environment(for example, two regions RegionOne and
> RegionTwo), KeyStone will be shared in RegionOne and RegionTwo, so the
> primary node and subnode should use different role, one role to enable the
> keystone, while another role is to use the keystone in another node, only one
> role to support multi-region setup seems to be not possible. The flag
> "MULTI_REGION" is to make the subnode play with the role where no keystone
> will run. If we don't use the flag, or maybe use DEVSTACK_GATE_MULTI_REGION?
>
> This is the first patch in devstack-gate for me, any help or guide will be
> appreciated.
Basically, it's more of a note for myself at this point.
We don't directly expose a way to define a role in
devstack-gate[1][2][3][4]. We do a lot of heuristics to detect whether
or not the node is a primary node or a subnode.
Ideally, we should really have an environment variable ($ROLE ?) that
can be set by projects in project-config, and just call the test matrix
script[5] with the role that is being set in the environment variable.
Because otherwise we end up with more if/else checks on random variables
like your patch and the MULTI_KEYSTONE[6] patch, and eventually it
becomes very difficult to maintain and add to.
Does this make sense?
[1]:
https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L230
[2]:
https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L259
[3]:
https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L642
[4]:
https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L121
[5]:
https://github.com/openstack-infra/devstack-gate/blob/8740b6075b53e3c9bfda76d022fcc53904594e9c/devstack-vm-gate.sh#L265
[6]: https://review.openstack.org/#/c/394895/
--
Sean M. Collins
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
