In order to do a developer mode that allows installation of packages
from local file, which take precedence over the developer_mode
constraints, we need to allow the order of the constraints to be
changed.
This patch adds a "pip_install_developer_constraints" var which is used
to set the developer mode constraints. By default this will leave the
same behaviour but will allow additional constraints to be added, or the
developermode constraints file to be overriden altogether.
Change-Id: Ic1e11482673df6da3a13c63947ccd27711a1248a
In order to make it easier to detect the currently deployed
venv for a service, and therefore allow smarter decisions
for things like upgrading, we implement the venv tag as a
local fact.
The file used to store facts will be the same for all
OpenStack services, with each service using its own section.
Example:
"ansible_local": {
"openstack_ansible": {
"rally": {
"venv_tag": "14.2.1"
}
}
}
Change-Id: Icdc4a3bf4e802d8065105155aad207192d2df266
We use an SSH bastion host which we do our deployment through. The
deployment host doesn't have direct access to the same network as the
host. As a result the venv local checksum lookup fails.
I have described this here:
https://bugs.launchpad.net/openstack-ansible/+bug/1689283
This is a simple fix for this problem, assuming everything is good it
will need repeating in multiple places in the code base.
Change-Id: Ifeb9be248764abd091392a793954173f866ac708
Consolidate distro package install tasks into a
single task using the package module. Tidy up
some other tasks to reduce task file sprawl and
consolidate some task actions.
The minimum Ansible version is raised to 2.2 due to a
known bug [1] in Ansible's apt module which does not
update the cache properly if the cache update and the
install are combined in a single task.
[1] https://github.com/ansible/ansible-modules-core/issues/1497
Change-Id: I95e02c2786b3a21b6188a5930fb827b6ab04fadb
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 text given when there is a missing rally database was recently
changed. Update the 'Create/upgrade Rally DB schema' task to look for
the updated text so that the rally database can be created as required.
Change-Id: I705148e8e3a4691d6922ce295719c0785d9a8cfb
please see https://github.com/fireteam/virtualenv-tools/issues/5
This make installation of the virtualenv impossible on CentOS7 since
you endup with python > python2.7 and python2.7 > python
lrwxrwxrwx. 1 root root 9 Nov 24 20:49 python -> python2.7
lrwxrwxrwx. 1 root root 6 Nov 14 20:03 python2 -> python
lrwxrwxrwx. 1 root root 6 Nov 14 20:03 python2.7 -> python
Change-Id: I81d290d686582b23067e519285d27b9d4855c9e1
Related-Bug: #1637509
Partial-Bug: #1644629
Reinitializes (copies python, etc binaries) into the venv when
dropping a new venv into place. This is needed because the Python
binary packaged with the venv may not match the Python running on
the host it is being installed to. (ie. in the case of a Xenial
repo container and a Trusty target host.)
Change-Id: Ifbe100a7052e41a2e6e4c601287749e2a8dfd0e0
Partial-Bug: #1637509
Ansible 2.2 now treats the 'name' argument for the pip module
as a list, removing the need for us to implement the join
filter to optimise the install execution.
Change-Id: Ic1692285855c4924a4cde2ddce3735e9257857b3
Starting in Ansible 2.0, the get_url [1] module provides the
ability for a checksum to be provided to the get_url module
which will be verified against the local destination file
and the task skipped if it matches.
[1] http://docs.ansible.com/ansible/get_url_module.html
This patch implements the use of this functionality.
The ability to ignore a venv download failure is also removed
as this is not necessary or desirable. It is better for the
download to fail and the playbook execution to stop immediately
so that the failure point is exposed.
Change-Id: Ic39e5dcdaa5ff9badb37b01e37097f5d8bdf6bac
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
This change removes the use of 'ignore_errors: true' because it causes deployers
to see red output and a stacktrace, which traditionally means something is broken,
even when the failure is known to have a fall back option or be intentional. This
conversion will provide a generally cleaner interface.
It should be noted that the 'failed' filter will still function normally. Tasks
with the 'failed_when: false' option will still be marked as 'failed' in any
registered variable. This change simply makes the output look cleaner.
Change-Id: I5986a6588788b09501935fcd0fc18b96531bdca2
Closes-Bug: #1633438
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
Ansible 2.1.1 introduces a regression in the way conditional
includes are handled which results in every task in the
included file being evaluated even if the condition for the
include is not met. This extends the run time significantly
for a deployment.
This patch forces all conditional includes to be dynamic.
Change-Id: I6029769c2fe0847a2d8fcbd62cdc41168fc89a60
Related-Bug: https://github.com/ansible/ansible/issues/17687
In order to make it easier to differentiate between the lists of
python packages, distribution packages, downloaded packages,
package pins and other similar variables the variable names are
being changed to ensure that they have a more explicit suffix
that defines the purpose and makes the naming more consistent.
This is to facilitate a lookup plugin which will be able to look
up all the package lists and present them as a consolidated piece
of data which may be used for artifact preparation.
Change-Id: I85fe0d5f4235c5d71ff1e8fc4066a9d1e0932684
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 numerous tags within the role have been condensed
to two tags: rally-install and rally-config
These tags have been chosen as they are namespaced
and cover the two major functions of the role.
Change-Id: I781eb1edc8ea1d8bb093a579b9bb88498ed2d534
The default value of "rally_all" remains, but this
allows deployers to target the role to multiple
groups now.
Change-Id: Id1bbda227032f66270fe5656250be7794a1dd4af
The role gate will now actually run simple
Rally scenario against Keystone to validate that
the install and configuration is correct.
Change-Id: Ie5d52636700e8c276b0e793e815ae513d25415bb
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
Unlike the Ansible apt module, the Ansible pip module does not
recognise a with_items list and process all the items at once.
To optimise the pip install tasks, this patch replaces the use
of with_items with a join filter so that the pip install task
does an install with all the packages in a list, ensuring that
the execution is one action instead of many.
Change-Id: I403e36a67d2e06f5cd32fe28222b597a17ef42a1
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
Currently all pip install tasks only require the package to be
present. This means that when an environment undergoes a minor
upgrade the package is not upgraded to the same version that
was tested with. This ultimately results in a deployed
environment that does not match the tested environment.
While for the services installed into venvs this is not an
issue, it does affect those which do not use venvs and any
packages which are installed outside of a venv or on top
of a venv.
This patch changes the behaviour to ensure that the install
task will always use the latest available package. In
developer_mode this will mean using the version specified
in upper-constraints, and in an integrated build this will
mean the version which is available in the wheel repo's
folder for the tag.
Change-Id: I04455f7323e6c565e46203494876e1812c5d0c1e
