Rally does not adhere to the global requirements process, so its
requirements extend beyond those managed by upper-constraints, and
sometimes are incompatible with upper constraints.
We have no need to track their development from git commit to git
commit, and can rather rely on stable releases which we verify are
working with the upper constraints whenever we do a pinning bump.
This keeps things simpler for us, and also allows the repo build
process in the integrated build to do a constrained venv build
instead of doing it unconstrained and breaking stable branch builds
down the line.
Depends-On: https://review.openstack.org/570906
Change-Id: If3d0120cf6f6f78463cf7805bc046382c3b6d44e
The cmd2-0.9.0 is python3-only and the rally venv is built
unconstrained, so it's trying to bring in the latest version
which is incompatible with python2. We pin the library to
ensure that the venv build completes correctly.
We also re-arrange the package list to be alphabetically
sorted.
Depends-On: https://review.openstack.org/570879
Change-Id: I1e259ce98fc8517c0cd00a04d6fe7b3f0703f5b4
virtualenv-tools has a bug which gets triggered in gates: it can't
change the shebang of a virtualenv python bin/ files if they
were generated with a virtualenv script whose shebang ends with
python2 instead of python.
Because we can't modify virtualenv-tools, we use shell scripts
instead.
Change-Id: I438ae40b42bcf61a1be56a5f52581444a9b181a3
Partial-Bug: #1741634
Rally installs ansible, in an unconstrained way.
To pass linters, we skip the lint job on the test
shell command.
Change-Id: Ic830cf81b3cc691aafb7a97819e0ce68e48dd809
Fixes the ability to deploy a venv in cases where:
1) developer_mode is not enabled
2) A cached venv is not downloaded from the repo server
Additional cleanup to the developer_mode venv deployment
logic is implemented by adding a *_venv_download var
which is used to decouple developer_mode from the
cached venv extraction process so that a deployer
can force venv builds in-place (disable cached
venv usage) without enabling developer mode
constraints.
Change-Id: I6939e47455898c07003f1b480e6d65b5d06e4c68
The current constraints generation for the
installation involves multiple tasks and multiple
variables.
Using multiple tasks extends the installation time
unnecessarily and the additional variables are
unnecessary.
This patch aims to simplify the mechanism and
hopes to speed it up a little.
Change-Id: I4633c71c515ab03a4e72ef08e1bb682dedc8c079
It was duplicating the meaning/purpose of the role
variable `rally_role_project_group`
Also ensure that additional tasks are limited to only
a single host in the host group.
Change-Id: I3d5cc822cc0d3c2b0b3ba7b05a9fe1b6b9e3a839
The default value of "rally_all" remains, but this
allows deployers to target the role to multiple
groups now.
Change-Id: Id1bbda227032f66270fe5656250be7794a1dd4af
This patch adds a var used by the repo_build process to determine
which host group to check for members of before building the pip
packages required by this role. This provides the ability to
optimise the repo build process to only building the packages
that are required for an environment.
Depends-On: Idda16b4f382eee57c7469af898859d6d81d4eb30
Change-Id: Iedb4c0c91daa291f881a9fc00c5b8c40bb312ce3
The current method of installing the distribution packages required is
set in the tasks and cannot be changed by a deployer.
Currently the apt task always installs the latest package. This results
in unexpected binary changes when a deployer may simply be trying to
execute a configuration change.
This patch adds the ability for a deployer to change the desired state
so that the results are predictable.
Change-Id: I1708ca8285ffa2bbd1a989b187ef3c6d9dd005c2
Remove all tasks and variables related to toggling between installation
of rally inside or outside of a Python virtual environment.
Installing within a venv is now the only supported deployment.
Additionally, a few changes have been made to make the creation of the
venv more resistant to interruptions during a run of the role.
* unarchiving a pre-built venv will now also occur when the venv
directory is created, not only after being downloaded
* virtualenv-tools is run against both pre-built and non pre-built venvs
to account for interruptions during or prior to unarchiving
Change-Id: I815dff623fce1440a5d60f64bf69f4f563371998
Implements: blueprint only-install-venvs
Debian-specific vars and logic have been moved to tasks
that will execute only on those distributions.
Change-Id: I6a9d04382b1f1badebf12483ce7d1d02b43f8903
Implements: blueprint multi-platform-host
