e1cda1ca59
Extend the devstack job so that it can support both single and multinode cases. Multinode mode require extra settings in devstack configuration, some of which as subnode specific, some controller specific. Also keep a simple devstack-multinode job defined for now so we can run a multinode job in devstack gate, until the full tempest multinode job is ready to match the old gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial-nv. Fixing multinode also requires sharing the CA configuration between controller and peers, overlay network configuration for communication between virtual machines and running discover_hosts for nova after the subnode has been setup. The extra orchestration required for multinode is encoded in a dedicated role to allow for jobs in other repos to re-use it. This backport is slightly modified from the original, since master does not use the test-matrix anymore, while on stable branches we still rely on it. Change-Id: I2dcbd9bdb401860820e655d97aa3c4775af2827f |
||
|---|---|---|
| .. | ||
| defaults | ||
| tasks | ||
| README.rst | ||
README.rst
Orchestrate a devstack
Runs devstack in a multinode scenario, with one controller node and a group of subnodes.
The reason for this role is so that jobs in other repository may run devstack in their plays with no need for re-implementing the orchestration logic.
The "run-devstack" role is available to run devstack with no orchestration.
This role sets up the controller and CA first, it then pushes CA data to sub-nodes and run devstack there. The only requirement for this role is for the controller inventory_hostname to be "controller" and for all sub-nodes to be defined in a group called "subnode".
Role Variables