diff options
| author | Tobias Henkel <tobias.henkel@bmw.de> | 2019-01-19 13:33:39 +0100 |
|---|---|---|
| committer | Tobias Henkel <tobias.henkel@bmw.de> | 2019-03-15 09:09:16 +0100 |
| commit | cd9827e6649b7f14513c2f201afc9e9d46998ddb (patch) | |
| tree | f89c2370385812fa82b64bd61a63a34a508d19c0 /doc/source/developer/ansible.rst | |
| parent | c91335b5279872d90b285b087a0c2ddb85fc4f77 (diff) | |
| download | zuul-cd9827e6649b7f14513c2f201afc9e9d46998ddb.tar.gz | |
Manage ansible installations within zuul
As a first step towards supporting multiple ansible versions we need
tooling to manage ansible installations. This moves the installation
of ansible from the requirements.txt into zuul. This is called as a
setup hook to install the ansible versions into
<prefix>/lib/zuul/ansible. Further this tooling abstracts knowledge
that the executor must know in order to actually run the correct
version of ansible.
The actual usage of multiple ansible versions will be done in
follow-ups.
For better maintainability the ansible plugins live in
zuul/ansible/base where plugins can be kept in different versions if
necessary. For each supported ansible version there is a specific
folder that symlinks the according plugins.
Change-Id: I5ce1385245c76818777aa34230786a9dbaf723e5
Depends-On: https://review.openstack.org/623927
Diffstat (limited to 'doc/source/developer/ansible.rst')
| -rw-r--r-- | doc/source/developer/ansible.rst | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/doc/source/developer/ansible.rst b/doc/source/developer/ansible.rst index c5fcbb442..6e588ed0f 100644 --- a/doc/source/developer/ansible.rst +++ b/doc/source/developer/ansible.rst @@ -23,7 +23,7 @@ execution to ensure local actions are not executed or that for operations that are desirable to allow locally that they only interact with files in the zuul work directory. -.. autoclass:: zuul.ansible.action.normal.ActionModule +.. autoclass:: zuul.ansible.base.action.normal.ActionModule :members: Build Log Support @@ -38,16 +38,16 @@ for the command to finish. Zuul contains a modified version of the :ansible:module:`command` that starts a log streaming daemon on the build node. -.. automodule:: zuul.ansible.library.command +.. automodule:: zuul.ansible.base.library.command -All jobs run with the :py:mod:`zuul.ansible.callback.zuul_stream` callback +All jobs run with the :py:mod:`zuul.ansible.base.callback.zuul_stream` callback plugin enabled, which writes the build log to a file so that the :py:class:`zuul.lib.log_streamer.LogStreamer` can provide the data on demand over the finger protocol. Finally, :py:class:`zuul.web.LogStreamHandler` exposes that log stream over a websocket connection as part of :py:class:`zuul.web.ZuulWeb`. -.. autoclass:: zuul.ansible.callback.zuul_stream.CallbackModule +.. autoclass:: zuul.ansible.base.callback.zuul_stream.CallbackModule :members: .. autoclass:: zuul.lib.log_streamer.LogStreamer @@ -55,7 +55,7 @@ exposes that log stream over a websocket connection as part of .. autoclass:: zuul.web.ZuulWeb In addition to real-time streaming, Zuul also installs another callback module, -:py:mod:`zuul.ansible.callback.zuul_json.CallbackModule` that collects all +:py:mod:`zuul.ansible.base.callback.zuul_json.CallbackModule` that collects all of the information about a given run into a json file which is written to the work dir so that it can be published along with build logs. Since the streaming log is by necessity a single text stream, choices have to be made for @@ -63,4 +63,4 @@ readability about what data is shown and what is not shown. The json log file is intended to allow for a richer more interactive set of data to be displayed to the user. -.. autoclass:: zuul.ansible.callback.zuul_json.CallbackModule +.. autoclass:: zuul.ansible.base.callback.zuul_json.CallbackModule |