Currently, stack_install_service will accept any service name. This is
problematic because a project plugin can pass an invalid name without
noticing. This has been the case in ironic-inspector[0].
This commit ensures that stack_install_service will not silently fail
when passing an invalid service name.
[0] https://review.openstack.org/#/c/424680/
Change-Id: I1a8105bdbaf4aecb630df08da416808bf7180824
Closes-Bug: #1659042
Add USE_PYTHON3 and PYTHON3_VERSION variables to allow services to use
python 3 if they indicate support in their python package metadata.
Tested in Heat here -> I837c2fba682ab430d50e9f43913f2fed20325a7a.
Project config change to add a dedicated job to Heat is here -> I0837e62d6ccc66397a5e409f0961edd4be31f467
Change-Id: I079e18b58b214bf8362945c253d6d894ca8b1a6b
Adds USE_VENV to globally enable/disable use of virtual environments.
ADDITIONAL_VENV_PACKAGES is used to manually add packages that do not
appear in requirements.txt or test-requirements.txt to be installed
into each venv. Database Python bindings are handled this way when
a dataabse service is enabled.
Change-Id: I9cf298b936fd10c95e2ce5f51aab0d49d4b7f37f
There were a couple of places where TOP_DIR is missing when we do a
source of content in tools. Given that working directory can change
quite often during devstack, we need to always be explicit here.
Change-Id: I14b5699637d7f5db745bccf116f440cdcbaa8d91
Introduce the tooling to build virtual environments.
* tools/build_venv.sh: build a venv
* introduce lib/stack to house functionality extracted from stack.sh that
is needed in other places, such as Grenade; start with stack_install_service
to wrap the venv install mechanics
* declare PROJECT_VENV array to track where project venvs should be installed
* create a venv for each project defined in PROJECT_VENV in stack_install_service()
Change-Id: I508588c0e2541b976dd94569d44b61dd2c35c01c