mirror of https://github.com/ansible/ansible.git
Docs [2.10] Backportapalooza 6 (#71129)
* Misc typo fixes (#71089) (cherry picked from commitpull/71165/head504ef607f3) * Add some documentation for the format of meta/runtime.yml (#71035) * Document the format of meta/runtime.yml * Document multiple Ansible versions Clarify difference between deprecation and tombstone fields * add note (cherry picked from commita9eb8b0488) * add note to uninstall older versions of ansible for pip (#71023) * add note to uninstall older versions of ansible for pip * combine with the other PR (cherry picked from commit72d3d44163) * VMware: Inventory scenario guide for hostnames (#71055) Added a scenario guide for ``hostnames`` parameter for vmware_vm_inventory. Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com> (cherry picked from commit0055673c70) * Document string tests a bit more (#71049) - Explain how `regex` differs from `match` and `search`. - Document `multiline` and `ignorecase`. Signed-off-by: Rick Elrod <rick@elrod.me> (cherry picked from commit701c638757) * docs: Add a note about package requirements for fact gathering (#70796) Fixes: #26148 Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com> (cherry picked from commita6725d6e2a) * added note about fakeroot (#71018) see #70895 (cherry picked from commit11a31e99e6) * Update documentation of httpapi's handle_httperror method for clarity (#70991) (cherry picked from commita0523e5b8a) * DOCS: add 2.10 collections roadmap (#70975) * draft of 2.10 collections roadmap * incorporates feedback from felixfontein * gundalow and samccann feedback, fix link Co-authored-by: Alicia Cozine <acozine@users.noreply.github.com> (cherry picked from commit9879da8e23) * updates changelog types; some updates for easier translation (#71027) Co-authored-by: Alicia Cozine <acozine@users.noreply.github.com> Co-authored-by: Felix Fontein <felix@fontein.de> (cherry picked from commit4f4436c124) * Document common return values with examples (#71046) * adding return value examples * shift to console code blocks * cleaning up whitespace and shortening invocation example * reordering diff section (cherry picked from commit864573a38d) * Update intro_getting_started.rst (#71039) Added two additional learning resources in the See also: section- forgot closing backticks (cherry picked from commit9850915bd6) * Guide users to use ansible-runner (#71063) Update the docs to guide users to use `ansible-runner` instead of using Python API directly. In many use cases, executing Ansible playbooks are sufficient. In those use cases, `ansible-runner` is easier and much stable to use comparing with Python API, but there is no mention of it. (cherry picked from commit0c855dc70b) * Porting guides for ansible-base 2.10 and ansible 2.10 (#70891) * Fix changelog link title. * Rename Ansible 2.10 and 2.11 porting guides to Ansible-base porting guides. * Add stub for automatically generated 2.10 porting guide. * Move things that should not be in the ansible-base porting guide to the ansible porting guide. * Apply changes to base porting guides. * Add remark that ansible-base is mainly for developers. * Ansible Base -> Ansible-base * Fix link in base porting guide. * Add generated porting guide. * Use same header signs as antsibull-changelog's RST builder. * Update generated porting guide. (cherry picked from commit61b36c6f30) * Update network platform guides with FQCN (#70699) * fqcn all the docs things! (cherry picked from commit54bee7152b) * Document how to upgrade to ansible with pip (#70768) Fixes #70348 (cherry picked from commit5019335660) * document how to migrate between collections (#70243) * document how to migrate between collections * Apply suggestions from code review Co-authored-by: John R Barker <john@johnrbarker.com> Co-authored-by: Felix Fontein <felix@fontein.de> (cherry picked from commit58145dff9c) * remove github link from plugins (#70951) (cherry picked from commite28b20d729) * Add latest rc from ansible-base (#70974) * Add latest rc from ansible-base (cherry picked from commitd62dffafb3) * Document to_json will convert to ASCII strings by default (#70954) ... as reported in issue #68702 (cherry picked from commit8c48366f1c) * Update the porting guide for ansible-2.10.0a8 (#71141) (cherry picked from commit0a9638ce4b) Co-authored-by: Abhijeet Kasurde <akasurde@redhat.com> Co-authored-by: Sloane Hertel <shertel@redhat.com> Co-authored-by: Rick Elrod <rick@elrod.me> Co-authored-by: Brian Coca <bcoca@users.noreply.github.com> Co-authored-by: Nathaniel Case <ncase@redhat.com> Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com> Co-authored-by: Terciero <terciero@users.noreply.github.com> Co-authored-by: Brendon O'Sullivan <49501251+bjosullivan@users.noreply.github.com> Co-authored-by: EthanHur <ethan0311@gmail.com> Co-authored-by: Felix Fontein <felix@fontein.de> Co-authored-by: Baptiste Mille-Mathias <baptiste.millemathias@gmail.com> Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>
Sandra McCann
4 years ago
committed by
GitHub
parent
4b03d898f3
commit
b9a406f890
@ -0,0 +1,156 @@
|
||||
|
||||
.. _porting_2.11_guide_base:
|
||||
|
||||
*******************************
|
||||
Ansible-base 2.11 Porting Guide
|
||||
*******************************
|
||||
|
||||
This section discusses the behavioral changes between Ansible-base 2.10 and Ansible-base 2.11.
|
||||
|
||||
It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible-base.
|
||||
|
||||
We suggest you read this page along with the `Ansible-base Changelog for 2.11 <https://github.com/ansible/ansible/blob/stable-2.11/changelogs/CHANGELOG-v2.11.rst>`_ to understand what updates you may need to make.
|
||||
|
||||
Ansible-base is mainly of interest for developers and users who only want to use a small, controlled subset of the available collections. Regular users should install ansible.
|
||||
|
||||
The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
|
||||
|
||||
.. contents::
|
||||
|
||||
|
||||
Playbook
|
||||
========
|
||||
|
||||
* Fixed a bug on boolean keywords that made random strings return 'False', now they should return an error if they are not a proper boolean
|
||||
Example: `diff: yes-` was returning `False`.
|
||||
* A new fact, ``ansible_processor_nproc`` reflects the number of vcpus
|
||||
available to processes (falls back to the number of vcpus available to
|
||||
the scheduler).
|
||||
|
||||
|
||||
Command Line
|
||||
============
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Deprecated
|
||||
==========
|
||||
|
||||
* Windows Server 2008 and 2008 R2 will no longer be supported or tested in the next Ansible release, see :ref:`windows_faq_server2008`.
|
||||
|
||||
|
||||
Modules
|
||||
=======
|
||||
|
||||
Change to Default File Permissions
|
||||
----------------------------------
|
||||
|
||||
To address CVE-2020-1736, the default permissions for certain files created by Ansible using ``atomic_move()`` were changed from ``0o666`` to ``0o600``. The default permissions value was only used for the temporary file before it was moved into its place or newly created files. If the file existed when the new temporary file was moved into place, Ansible would use the permissions of the existing file. If there was no existing file, Ansible would retain the default file permissions, combined with the system ``umask``, of the temporary file.
|
||||
|
||||
Most modules that call ``atomic_move()`` also call ``set_fs_attributes_if_different()`` or ``set_mode_if_different()``, which will set the permissions of the file to what is specified in the task.
|
||||
|
||||
A new warning will be displayed when all of the following conditions are true:
|
||||
|
||||
- The file at the final destination, not the temporary file, does not exist
|
||||
- A module supports setting ``mode`` but it was not specified for the task
|
||||
- The module calls ``atomic_move()`` but does not later call ``set_fs_attributes_if_different()`` or ``set_mode_if_different()`` with a ``mode`` specified
|
||||
|
||||
The following modules call ``atomic_move()`` but do not call ``set_fs_attributes_if_different()`` or ``set_mode_if_different()`` and do not support setting ``mode``. This means for files they create, the default permissions have changed and there is no indication:
|
||||
|
||||
- M(known_hosts)
|
||||
- M(service)
|
||||
|
||||
|
||||
Code Audit
|
||||
~~~~~~~~~~
|
||||
|
||||
The code was audited for modules that use ``atomic_move()`` but **do not** later call ``set_fs_attributes_if_different()`` or ``set_mode_if_different()``. Modules that provide no means for specifying the ``mode`` will not display a warning message since there is no way for the playbook author to remove the warning. The behavior of each module with regards to the default permissions of temporary files and the permissions of newly created files is explained below.
|
||||
|
||||
known_hosts
|
||||
^^^^^^^^^^^
|
||||
|
||||
The M(known_hosts) module uses ``atomic_move()`` to operate on the ``known_hosts`` file specified by the ``path`` parameter in the module. It creates a temporary file using ``tempfile.NamedTemporaryFile()`` which creates a temporary file that is readable and writable only by the creating user ID.
|
||||
|
||||
service
|
||||
^^^^^^^
|
||||
|
||||
The M(service) module uses ``atomic_move()`` to operate on the default rc file, which is the first found of ``/etc/rc.conf``, ``/etc/rc.conf.local``, and ``/usr/local/etc/rc.conf``. Since these files almost always exist on the target system, they will not be created and the existing permissions of the file will be used.
|
||||
|
||||
**The following modules were included in Ansible <= 2.9. They have moved to collections but are documented here for completeness.**
|
||||
|
||||
authorized_key
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
The M(authorized_key) module uses ``atomic_move()`` to operate on the the ``authorized_key`` file. A temporary file is created with ``tempfile.mkstemp()`` before being moved into place. The temporary file is readable and writable only by the creating user ID. The M(authorized_key) module manages the permissions of the the ``.ssh`` direcotry and ``authorized_keys`` files if ``managed_dirs`` is set to ``True``, which is the default. The module sets the ``ssh`` directory owner and group to the ``uid`` and ``gid`` of the user specified in the ``user`` parameter and directory permissions to ``700``. The module sets the ``authorized_key`` file owner and group to the ``uid`` and ``gid`` of the user specified in the ``user`` parameter and file permissions to ``600``. These values cannot be controlled by module parameters.
|
||||
|
||||
interfaces_file
|
||||
^^^^^^^^^^^^^^^
|
||||
The M(interfaces_file) module uses ``atomic_move()`` to operate on ``/etc/network/serivces`` or the ``dest`` specified by the module. A temporary file is created with ``tempfile.mkstemp()`` before being moved into place. The temporary file is readable and writable only by the creating user ID. If the file specified by ``path`` does not exist it will retain the permissions of the temporary file once moved into place.
|
||||
|
||||
pam_limits
|
||||
^^^^^^^^^^
|
||||
|
||||
The M(pam_limits) module uses ``atomic_move()`` to operate on ``/etc/security/limits.conf`` or the value of ``dest``. A temporary file is created using ``tempfile.NamedTemporaryFile()``, which is only readable and writable by the creating user ID. The temporary file will inherit the permissions of the file specified by ``dest``, or it will retain the permissions that only allow the creating user ID to read and write the file.
|
||||
|
||||
pamd
|
||||
^^^^
|
||||
|
||||
The M(pamd) module uses ``atomic_move()`` to operate on a file in ``/etc/pam.d``. The path and the file can be specified by setting the ``path`` and ``name`` parameters. A temporary file is created using ``tempfile.NamedTemporaryFile()``, which is only readable and writable by the creating user ID. The temporary file will inherit the permissions of the file located at ``[dest]/[name]``, or it will retain the permissions of the temporary file that only allow the creating user ID to read and write the file.
|
||||
|
||||
redhat_subscription
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The M(redhat_subscription) module uses ``atomic_move()`` to operate on ``/etc/yum/pluginconf.d/rhnplugin.conf`` and ``/etc/yum/pluginconf.d/subscription-manager.conf``. A temporary file is created with ``tempfile.mkstemp()`` before being moved into place. The temporary file is readable and writable only by the creating user ID and the temporary file will inherit the permissions of the existing file once it is moved in to place.
|
||||
|
||||
selinux
|
||||
^^^^^^^
|
||||
|
||||
The M(selinux) module uses ``atomic_move()`` to operate on ``/etc/selinux/config`` on the value specified by ``configfile``. The module will fail if ``configfile`` does not exist before any temporary data is written to disk. A temporary file is created with ``tempfile.mkstemp()`` before being moved into place. The temporary file is readable and writable only by the creating user ID. Since the file specified by ``configfile`` must exist, the temporary file will inherit the permissions of that file once it is moved in to place.
|
||||
|
||||
sysctl
|
||||
^^^^^^
|
||||
|
||||
The M(sysctl) module uses ``atomic_move()`` to operate on ``/etc/sysctl.conf`` or the value specified by ``sysctl_file``. The module will fail if ``sysctl_file`` does not exist before any temporary data is written to disk. A temporary file is created with ``tempfile.mkstemp()`` before being moved into place. The temporary file is readable and writable only by the creating user ID. Since the file specified by ``sysctl_file`` must exist, the temporary file will inherit the permissions of that file once it is moved in to place.
|
||||
|
||||
.. warning::
|
||||
|
||||
Links on this page may not point to the most recent versions of modules. We will update them when we can.
|
||||
|
||||
|
||||
Noteworthy module changes
|
||||
-------------------------
|
||||
|
||||
* Ansible modules created with ``add_file_common_args=True`` added a number of undocumented arguments which were mostly there to ease implementing certain action plugins. The undocumented arguments ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode`` are now no longer added. Modules relying on these options to be added need to specify them by themselves.
|
||||
* Ansible no longer looks for Python modules in the current working directory (typically the ``remote_user``'s home directory) when an Ansible module is run. This is to fix becoming an unprivileged user on OpenBSD and to mitigate any attack vector if the current working directory is writable by a malicious user. Install any Python modules needed to run the Ansible modules on the managed node in a system-wide location or in another directory which is in the ``remote_user``'s ``$PYTHONPATH`` and readable by the ``become_user``.
|
||||
|
||||
|
||||
Plugins
|
||||
=======
|
||||
|
||||
Lookup plugin names case-sensitivity
|
||||
------------------------------------
|
||||
|
||||
* Prior to Ansible ``2.10`` lookup plugin names passed in as an argument to the ``lookup()`` function were treated as case-insensitive as opposed to lookups invoked via ``with_<lookup_name>``. ``2.10`` brings consistency to ``lookup()`` and ``with_`` to be both case-sensitive.
|
||||
|
||||
Noteworthy plugin changes
|
||||
-------------------------
|
||||
|
||||
* Cache plugins in collections can be used to cache data from inventory plugins. Previously, cache plugins in collections could only be used for fact caching.
|
||||
* Some undocumented arguments from ``FILE_COMMON_ARGUMENTS`` have been removed; plugins using these, in particular action plugins, need to be adjusted. The undocumented arguments which were removed are ``src``, ``follow``, ``force``, ``content``, ``backup``, ``remote_src``, ``regexp``, ``delimiter``, and ``directory_mode``.
|
||||
|
||||
Action plugins which execute modules should use fully-qualified module names
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
* Action plugins that call modules should pass explicit, fully-qualified module names to ``_execute_module()`` whenever possible (eg, ``ansible.builtin.file`` rather than ``file``). This ensures that the task's collection search order is not consulted to resolve the module. Otherwise, a module from a collection earlier in the search path could be used when not intended.
|
||||
|
||||
Porting custom scripts
|
||||
======================
|
||||
|
||||
No notable changes
|
||||
|
||||
|
||||
Networking
|
||||
==========
|
||||
|
||||
No notable changes
|
||||
@ -0,0 +1,39 @@
|
||||
====================
|
||||
Ansible project 2.10
|
||||
====================
|
||||
|
||||
This release schedule includes dates for the `ansible <https://pypi.org/project/ansible/>`_ package, with a few dates for the `ansible-base <https://pypi.org/project/ansible-base/>`_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_10` for the most recent updates on ansible-base.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Release Schedule
|
||||
----------------
|
||||
|
||||
.. note:: Dates subject to change.
|
||||
.. note:: We plan to post weekly alpha releases to the `PyPI ansible project <https://pypi.org/project/ansible/>`_ for testing.
|
||||
|
||||
- 2020-06-23: ansible-2.10 alpha freeze.
|
||||
No net new collections will be added to the ``ansible-2.10`` package after this date.
|
||||
- 2020-07-10: Ansible collections freeze date for content shuffling.
|
||||
Content should be in its final collection for the ansible-2.10 series of releases. No more content should move out of the ``community.general`` or ``community.network`` collections.
|
||||
- 2020-08-13: ansible-base 2.10 Release date, see :ref:`base_roadmap_2_10`.
|
||||
- 2020-08-14: final ansible-2.10 alpha.
|
||||
- 2020-08-18: Ansible 2.10 beta freeze.
|
||||
- No new modules or major features will be added after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-1.1.0; ansible-2.10.0 could ship with community-crypto-1.1.1. It would not ship with community-crypto-1.2.0.
|
||||
- 2020-09-01: ansible-2.10.0 beta1.
|
||||
- 2020-09-08: ansible-2.10 final freeze/rc1.
|
||||
- After this date only changes blocking a release are accepted.
|
||||
- Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (on 9-10 and 9-17) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda <https://github.com/ansible/community/issues/539>`_.
|
||||
|
||||
** Additional release candidates to be published as needed as blockers are fixed **
|
||||
|
||||
- 2020-09-22: ansible-2.10 GA release date.
|
||||
|
||||
Ansible-2.10.x patch releases will occur roughly every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible-2.10.x patch releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed (example: Ansible-2.10 ships with community-crypto-1.1.0; ansible-2.10.1 may ship with community-crypto-1.2.0 but would not ship with community-crypto-2.0.0).
|
||||
|
||||
Breaking changes may be introduced in ansible-2.11.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly.
|
||||
|
||||
The rough schedule for Ansible-2.11 and beyond (such as how many months we'll aim for between versions) is still to be discussed and likely will be made after 2.10.0 has been released.
|
||||
|
||||
For more information, reach out on a mailing list or an IRC channel - see :ref:`communication` for more details.
|
||||
@ -0,0 +1,127 @@
|
||||
.. _vmware_ansible_inventory_using_hostnames:
|
||||
|
||||
*************************************************
|
||||
Using VMware dynamic inventory plugin - Hostnames
|
||||
*************************************************
|
||||
|
||||
.. contents:: Topics
|
||||
|
||||
VMware dynamic inventory plugin - Customizing hostnames
|
||||
=======================================================
|
||||
|
||||
|
||||
VMware inventory plugin allows you to configure hostnames using the ``hostnames`` configuration parameter.
|
||||
|
||||
In this scenario guide we will see how you configure hostnames from the given VMware guest in the inventory.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
To use the VMware dynamic inventory plugins, you must install `pyVmomi <https://github.com/vmware/pyvmomi>`_
|
||||
on your control node (the host running Ansible).
|
||||
|
||||
To include tag-related information for the virtual machines in your dynamic inventory, you also need the `vSphere Automation SDK <https://code.vmware.com/web/sdk/65/vsphere-automation-python>`_, which supports REST API features such as tagging and content libraries, on your control node.
|
||||
You can install the ``vSphere Automation SDK`` following `these instructions <https://github.com/vmware/vsphere-automation-sdk-python#installing-required-python-packages>`_.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install pyvmomi
|
||||
|
||||
Starting in Ansible 2.10, the VMware dynamic inventory plugin is available in the ``community.vmware`` collection included Ansible.
|
||||
To install the latest ``community.vmware`` collection:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible-galaxy collection install community.vmware
|
||||
|
||||
To use this VMware dynamic inventory plugin:
|
||||
|
||||
1. Enable it first by specifying the following in the ``ansible.cfg`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[inventory]
|
||||
enable_plugins = community.vmware.vmware_vm_inventory
|
||||
|
||||
2. Create a file that ends in ``.vmware.yml`` or ``.vmware.yaml`` in your working directory.
|
||||
|
||||
The ``vmware_vm_inventory`` inventory plugin takes in the same authentication information as any other VMware modules does.
|
||||
|
||||
Here's an example of a valid inventory file with custom hostname for the given VMware guest:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
plugin: community.vmware.vmware_vm_inventory
|
||||
strict: False
|
||||
hostname: 10.65.223.31
|
||||
username: administrator@vsphere.local
|
||||
password: Esxi@123$%
|
||||
validate_certs: False
|
||||
with_tags: False
|
||||
hostnames:
|
||||
- config.name
|
||||
|
||||
|
||||
Here, we have configured a custom hostname by setting the ``hostnames`` parameter to ``config.name``. This will retrieve
|
||||
the ``config.name`` property from the virtual machine and populate it in the inventory.
|
||||
|
||||
You can check all allowed properties for the given virtual machine at :ref:`vmware_inventory_vm_attributes`.
|
||||
|
||||
Executing ``ansible-inventory --list -i <filename>.vmware.yml`` will create a list of the virtual machines that are ready to be configured using Ansible.
|
||||
|
||||
What to expect
|
||||
--------------
|
||||
|
||||
You will notice that instead of default behavior of representing the hostname as ``config.name + _ + config.uuid``,
|
||||
the inventory hosts show value as ``config.name``.
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
{
|
||||
"_meta": {
|
||||
"hostvars": {
|
||||
"template_001": {
|
||||
"config.name": "template_001",
|
||||
"guest.toolsRunningStatus": "guestToolsNotRunning",
|
||||
...
|
||||
"guest.toolsStatus": "toolsNotInstalled",
|
||||
"name": "template_001"
|
||||
},
|
||||
"vm_8046": {
|
||||
"config.name": "vm_8046",
|
||||
"guest.toolsRunningStatus": "guestToolsNotRunning",
|
||||
...
|
||||
"guest.toolsStatus": "toolsNotInstalled",
|
||||
"name": "vm_8046"
|
||||
},
|
||||
...
|
||||
}
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
If the custom property specified in ``hostnames`` fails:
|
||||
|
||||
- Check if the values provided for username and password are correct.
|
||||
- Make sure it is a valid property, see :ref:`vmware_inventory_vm_attributes`.
|
||||
- Use ``strict: True`` to get more information about the error.
|
||||
- Please make sure that you are using latest version VMware collection.
|
||||
|
||||
|
||||
.. seealso::
|
||||
|
||||
`pyVmomi <https://github.com/vmware/pyvmomi>`_
|
||||
The GitHub Page of pyVmomi
|
||||
`pyVmomi Issue Tracker <https://github.com/vmware/pyvmomi/issues>`_
|
||||
The issue tracker for the pyVmomi project
|
||||
`vSphere Automation SDK GitHub Page <https://github.com/vmware/vsphere-automation-sdk-python>`_
|
||||
The GitHub Page of vSphere Automation SDK for Python
|
||||
`vSphere Automation SDK Issue Tracker <https://github.com/vmware/vsphere-automation-sdk-python/issues>`_
|
||||
The issue tracker for vSphere Automation SDK for Python
|
||||
:ref:`vmware_inventory_vm_attributes`
|
||||
Using Virtual machine attributes in VMware dynamic inventory plugin
|
||||
:ref:`working_with_playbooks`
|
||||
An introduction to playbooks
|
||||
:ref:`playbooks_vault`
|
||||
Using Vault in playbooks
|
||||
Loading…
Reference in New Issue