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: I1d6c3765e781b706244fdf0e91c1d6a51679d062
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: I60fbb95b55152c385364e10c25f52d10fa7ed75a
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: I5fc9c6899293dad7675ed4927e5c98047db6b485
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: I5e97ed325ba7971a1b483ac1278d0450026bdf18
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: I8e171fff9f83314caec5a5ec5173555e85f12676
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: Iea4689aa17b232911275d9a51cfbd5713b78a557
Related-Bug: https://github.com/ansible/ansible/issues/17687
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: I4ce24c9d557d173a452ee74a619c771b2bed5af8
The numerous tags within the role have been condensed
to two tags: designate-install and designate-config
These tags have been chosen as they are namespaced
and cover the two major functions of the role.
Documentation has been updated to inform how each tag
influences the function of the role.
Change-Id: I700b80bce2a8a761d341ca9cdc51398328966287
Remove all tasks and variables related to toggling between installation
of designate 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: If3f0cb96d0ac670f6c53243283d6726067cba011
Implements: blueprint only-install-venvs
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: I6cf37f1ce9c90a3a6c1b7f8aa793be9c260a5e25
* The default apt packages have been moved into a var file
that is only loaded when the detected OS is matched.
* The Install task file has had the apt specific tasks moved
into a named install task file.
Change-Id: I0b31d5d76d3aaedf3b87550165d0e670b314bebd
This commit changes the pip_install_options fact name in
designate_install.yml to pip_install_options_fact. This allows us to
maintain the existing pip_install_options variable without overwriting
it with options when in developer mode, which ultimately means we can
have multiple services running in a container use a combination of
*_developer_mode: true and *_developer_mode: false. At the moment,
if a service writes pip_install_options fact with the constraints
options, those options will persist to other services running in the
container even if *_developer_mode: false.
Change-Id: I9f47a143b3e79b35754584ae35fcbd9436479717
This patch implements a bunch of changes for easier debugging and to
make the deployment more functional.
- All passwords are removed from defaults. The role must fail to
complete all tasks if no password is provided.
- The Designate Pool Configuration uuid's are provided with
defaults and the vars are added to the user_secrets.yml file
for easy implementation in OpenStack-Ansible.
- The designate.conf template has been re-organised to closely
match the sample file provided in the master branch of the
OpenStack Designate repository. This makes it easier to compare
for changes.
- The PyMySQL driver is used for all MySQL connectivity, as is now
the general standard for OpenStack Services.
- The designate_pool_manager database is now setup.
- The test playbook has the RabbitMQ & DB setup pre_tasks removed
for now. These can move out again once functional testing is
working.
- The test playbook's LXC dhcp range is reduced to 50 hosts in
order to ensure no conflicts with the test containers and also
provide room for growth.
- Add human readable logging callback plugin to functional test.
- Restructure testing to make it easier to work with.
This commit adds the ability to install glance without requiring an
OpenStack-Ansible pip wheel repository.
In 'developer mode' the git source is cloned directly and the services
are installed directly from the git clone with its requirements being
installed from pypi. The OpenStack upper-constraints file is also used
to ensure that the install is executed using the appropriately tested
set of pypi packages.
The following variables are added:
- designate_developer_mode: A boolean switch to enable/disable developer
mode.
- designate_git_repo: The git repository to clone Designate from.
- designate_git_install_branch: The branch, tag or SHA to checkout once
the designate repository has been cloned.
- designate_requirements_git_repo: The git repository to clone in order
to retrieve the upper-constraints file.
- designate_requirements_git_install_branch: The branch, tag or SHA to
checkout once the requirements repository has been cloned.
The testing playbook overrides the *_install_branch variables to fixed
SHA's in order to fix points in time at which updates are made. This
reduces the effect of upstream development changes on the
OpenStack-Ansible development cycle.
