faee049e24
In order to radically simplify how we prepare the service venvs, we use a common role to do the wheel builds and the venv preparation. This makes the process far simpler to understand, because the role does its own building and installing. It also reduces the code maintenance burden, because instead of duplicating the build processes in the repo_build role and the service role - we only have it all done in a single place. We also change the role venv tag var to use the integrated build's common venv tag so that we can remove the role's venv tag in group_vars in the integrated build. This reduces memory consumption and also reduces the duplication. This is by no means the final stop in the simplification process, but it is a step forward. The will be work to follow which: 1. Replaces 'developer mode' with an equivalent mechanism that uses the common role and is simpler to understand. We will also simplify the provisioning of pip install arguments when doing this. 2. Simplifies the installation of optional pip packages. Right now it's more complicated than it needs to be due to us needing to keep the py_pkgs plugin working in the integrated build. 3. Deduplicates the distro package installs. Right now the role installs the distro packages twice - just before building the venv, and during the python_venv_build role execution. Depends-On: https://review.openstack.org/598957 Change-Id: I29833c41eba9b3ff80200b7f567a120f589e170e Implements: blueprint python-build-install-simplification Signed-off-by: Jesse Pretorius <jesse.pretorius@rackspace.co.uk> |
||
|---|---|---|
| .. | ||
| designate_db_setup.yml | ||
| designate_install.yml | ||
| designate_install_source.yml | ||
| designate_post_install.yml | ||
| designate_pre_install.yml | ||
| designate_service_setup.yml | ||
| main.yml | ||
| mq_setup.yml | ||