Merge "Add spec for multi ansible version support"
This commit is contained in:
commit
1ac2d852eb
|
@ -14,3 +14,4 @@ for those changes and help us work on them collaboratively.
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
|
|
||||||
container-build-resources
|
container-build-resources
|
||||||
|
multiple-ansible-versions
|
||||||
|
|
|
@ -0,0 +1,157 @@
|
||||||
|
Multiple Ansible versions
|
||||||
|
=========================
|
||||||
|
|
||||||
|
.. warning:: This is not authoritative documentation. These features
|
||||||
|
are not currently available in Zuul. They may change significantly
|
||||||
|
before final implementation, or may never be fully completed.
|
||||||
|
|
||||||
|
Currently zuul only supports one specific ansible version at once. This
|
||||||
|
complicates upgrading ansible because ansible often breaks backwards
|
||||||
|
compatibility and so we need to synchronize the upgrade on the complete
|
||||||
|
deployment which is often not possible.
|
||||||
|
|
||||||
|
Instead we want to support multiple ansible versions at once so we can handle
|
||||||
|
the lifecycle of ansible versions by adding new versions and deprecating old
|
||||||
|
ones.
|
||||||
|
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
------------
|
||||||
|
|
||||||
|
We want jobs to be able to pick a specific ansible version to run. However as we
|
||||||
|
have lots of stuff that overrides things in ansible we will let the job only
|
||||||
|
select a minor version (e.g. 2.6) in a list of supported versions. This is also
|
||||||
|
necessary from a security point of view so the user cannot pick a specific
|
||||||
|
bugfix version that is known to contain certain security flaws. Zuul needs to
|
||||||
|
support a list of specific minor versions from where it will pick the latest
|
||||||
|
bugfix version or a pinned version if we need to.
|
||||||
|
|
||||||
|
We need virtual environments for ansible which are not relocatable. Because of
|
||||||
|
this we must install ansible after the installation. Further we need to support
|
||||||
|
sdist based installations as well as wheel based installations. However wheel
|
||||||
|
based installations don't have any possibility for post install hooks. Thus
|
||||||
|
to stay consistent we will require to manually run a post installation script
|
||||||
|
to install the ansible versions. This script will work standalone as well as
|
||||||
|
within the executor process context. This will make it possible to let the
|
||||||
|
executor optionally install ansible at startup time if there is interest.
|
||||||
|
This can be useful for the quick start. However the recommended way will be the
|
||||||
|
manual run.
|
||||||
|
|
||||||
|
We also need a configuration that specifies additional packages that need to
|
||||||
|
be installed along with ansible. This is required because different deployers
|
||||||
|
use different ansible connections or modules that have additional optional
|
||||||
|
dependencies (e.g. winrm).
|
||||||
|
|
||||||
|
|
||||||
|
Job configuration
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
There will be a new job attribute ``ansible-version`` that will instruct zuul
|
||||||
|
to take the specified version. This attribute will be validated against a list
|
||||||
|
of supported ansible versions that zuul currently can handle. Zuul will throw
|
||||||
|
a configuration error if a job selects an unsupported or unparsable version.
|
||||||
|
If no ``ansible-version`` is defined zuul will pick up the ansible version
|
||||||
|
marked as default. We will also need a mechanism to deprecate ansible versions
|
||||||
|
to prepare removing old versions. We could add labels to the supported versions.
|
||||||
|
To express that. The supported versions we will start with will be:
|
||||||
|
|
||||||
|
* 2.5 (deprecated)
|
||||||
|
* 2.6
|
||||||
|
* 2.7 (default)
|
||||||
|
|
||||||
|
The default ansible version will be configurable on global and tenant level.
|
||||||
|
This way updating the default to newer versions can be made much less
|
||||||
|
disruptive. Being able to specify the default version on tenant level makes
|
||||||
|
it easy to canary release ansible updates in a larger multi tenant environment.
|
||||||
|
|
||||||
|
We will also need to be able to pin a version to a specific bugfix version in
|
||||||
|
case the latest one is known to be broken. This will also be handled by the
|
||||||
|
installation mechanisms described below.
|
||||||
|
|
||||||
|
|
||||||
|
Installing ansible
|
||||||
|
------------------
|
||||||
|
|
||||||
|
We currently pull in ansible via the ``requirements.txt``. This will no longer
|
||||||
|
be sufficient. Instead zuul itself needs to take care of installing the
|
||||||
|
supported versions into a pre-defined directory structure using the venv module.
|
||||||
|
The executor will have two new config options:
|
||||||
|
|
||||||
|
* ``ansible-root``: The root path where ansible installations will be found. The
|
||||||
|
default will be ``<exec-root>/lib/zuul/executor-ansible``. All supported
|
||||||
|
ansible installations will live inside a venv in the path
|
||||||
|
``ansible-root/<minor-version>``.
|
||||||
|
|
||||||
|
* ``manage-ansible``: A boolean flag that tells the executor manage the
|
||||||
|
installed ansible versions itself. The default will be ``true``.
|
||||||
|
|
||||||
|
If set to ``true`` the executor will install and upgrade all supported
|
||||||
|
ansible versions on startup.
|
||||||
|
|
||||||
|
If set to ``false`` the executor will validate the presence of all supported
|
||||||
|
ansible versions on startup and throw an error on missing installations.
|
||||||
|
|
||||||
|
The management of the ansible installations will be performed by a script
|
||||||
|
installed along the zuul binaries. This will install and update every supported
|
||||||
|
version of ansible into a specified ``ansible-root`` directory.
|
||||||
|
|
||||||
|
This script
|
||||||
|
can then be used by the executor or externally depending on the configuration.
|
||||||
|
|
||||||
|
|
||||||
|
Dockerized deployment
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
In a dockerized deployment it is preferable to pre-install ansible during the
|
||||||
|
image build. This can be done by calling the installation script during the
|
||||||
|
image build. The official images will contain all supported versions.
|
||||||
|
|
||||||
|
|
||||||
|
Ansible module overrides
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
We currently have many ansible module overrides. These may or may not be
|
||||||
|
targeted to a specific ansible version. Currently they are organized into the
|
||||||
|
folder ``zuul/ansible``. In order to support multiple ansible versions without
|
||||||
|
needing to fork everything there this will be reorganized into:
|
||||||
|
|
||||||
|
* ``zuul/ansible/generic``: Overrides and modules valid for all supported
|
||||||
|
ansible versions.
|
||||||
|
* ``zuul/ansible/<version>``: Overrides and modules valid for a specific
|
||||||
|
version.
|
||||||
|
|
||||||
|
If there are overrides that are valid for a range of ansible versions we can
|
||||||
|
define it in the lowest version and make use of symlinking to the other versions
|
||||||
|
in order to minimize additional maintenance overhead by not forking an override
|
||||||
|
where possible. Generally we should strive for having as much as possible in the
|
||||||
|
generic part to minimize the maintenance effort of these.
|
||||||
|
|
||||||
|
|
||||||
|
Deprecation policy
|
||||||
|
------------------
|
||||||
|
|
||||||
|
We should handle deprecating and removing supported ansible versions similar to
|
||||||
|
the deprecation policy described in zuul-jobs:
|
||||||
|
https://zuul-ci.org/docs/zuul-jobs/policy.html
|
||||||
|
|
||||||
|
Further we should make sure that whenever we release a new version of zuul we
|
||||||
|
should make sure that the list of supported ansible versions is a subset of
|
||||||
|
what is supported by ansible at that time. The list of supported ansible
|
||||||
|
versions can be found here:
|
||||||
|
https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#release-status
|
||||||
|
|
||||||
|
We also should notify the users when they use deprecated ansible versions. This
|
||||||
|
can be done in two ways. First the executor will emit a warning to the logs when
|
||||||
|
it encounters a job that uses a deprecated ansible version. The executor already
|
||||||
|
can return warnings together with the build result. These will be added directly
|
||||||
|
to the reporting to the code review system. This can be used to warn about
|
||||||
|
deprecated ansible versions at a prominent location instead of burying it
|
||||||
|
somewhere in megabytes of logs.
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
-------
|
||||||
|
|
||||||
|
We also have a set of tests that validate the security overrides. We need to
|
||||||
|
test them for all supported ansible versions. Where needed we also need to fork
|
||||||
|
or add additional version specific tests.
|
Loading…
Reference in New Issue