Browse Source

Merge "Add spec for multi ansible version support"

changes/28/636728/3
Zuul 2 years ago
committed by Gerrit Code Review
parent
commit
1ac2d852eb
2 changed files with 158 additions and 0 deletions
  1. +1
    -0
      doc/source/developer/specs/index.rst
  2. +157
    -0
      doc/source/developer/specs/multiple-ansible-versions.rst

+ 1
- 0
doc/source/developer/specs/index.rst View File

@ -14,3 +14,4 @@ for those changes and help us work on them collaboratively.
:maxdepth: 1
container-build-resources
multiple-ansible-versions

+ 157
- 0
doc/source/developer/specs/multiple-ansible-versions.rst View File

@ -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…
Cancel
Save