running chown and chmod on files and folders not created by
devstack causes a few issues:
* On nfs mounted directories it can take an extremely
long time to chown -R some of the git repos, especially
if any tox commands have been ran in the host
* chown can cause the host files to get into a weird state
if nfs is set up wrong.
If files and folders are pre-existing we should assume
they are in the correct state, and not modify them.
Fix setup-devstack-log-dir to create the logs directory with
correct permissions in the first place.
Change-Id: I5ebdaded3ffd0a5bc70c5e9ab5b18daefb358f58
Signed-off-by: Graham Hayes <gr@ham.ie>
When the role is used by grenade, the data directory is shared among
different devstack executions, and the base directory is different,
for example: /opt/stack/data vs /opt/stack/{old,new}.
The new devstack_data_base_dir parameter allows user to specify
a base directory for the data/ directory which is unrelated
to the devstack directory. The default value is devstack_base_dir,
so the default behavior is unchanged.
Change-Id: Ie69b7b51947cbf1a8b31d2701783de2fb56a2d33
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.
Change-Id: I2dcbd9bdb401860820e655d97aa3c4775af2827f
