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