mirror of https://github.com/ansible/ansible.git
Backport/2.9/docs2 (#62805)
* Update pip module docs (#62359) * Clarifying pip module requirements in reference to #47361 * Further clarifying message with link to ansible_python_interpreter (cherry picked from commitpull/62986/headd3ec5ca80f) * chore/doc-module: sts_assume_role.py (#62475) Update `Example` section with with the correct module usage. (cherry picked from commita4a216640f) * Improve dconf documentation to include conversion problems (#62316) (cherry picked from commit864928365e) * Add examples for various inventory setups to the documentation (#62323) * Updates docs/docsite/rst/user_guide/intro_inventory.rst, closes #12480. * Use code-block and rename groups in inventory setup examples * Fix group name in inventory setup example Co-Authored-By: Sandra McCann <samccann@redhat.com> (cherry picked from commit7047b66d34) * added networking porting guide info (#61999) * Update docs/docsite/rst/porting_guides/porting_guide_2.9.rst Co-Authored-By: Nathaniel Case <this.is@nathanielca.se> (cherry picked from commit6d35f9026f) * [docs] split collections into user and dev guide sections (#62363) (cherry picked from commit7badeb6df0) * fixed options (#62605) (cherry picked from commit170b4e63ff) * ec2_vpc_subnet: Rename resource_tags > tags (#62663) Most of the AWS module documentation refers to `tags` and not `resource_tags`. This patch updates the documentation to match other AWS module documentation. 😉 Signed-off-by: Major Hayden <major@redhat.com> (cherry picked from commitcced1a3cd1) * [Docs] Document the resource module builder (#62222) (cherry picked from commitb17581a307) * Fix link syntax and a typo in dev collections doc (#62650) (cherry picked from commit2969614c2c) * hcloud_volume: clarify volume size units (#62771) (cherry picked from commit190b8fcd1c) * ovirt_host update force doc (#62491) (cherry picked from commit3b2b418aad) * update example document for zabbix_action module (#62667) (cherry picked from commit3299f29f7c)
Sandra McCann
5 years ago
committed by
Alicia Cozine
parent
633b089930
commit
40c40a9653
@ -0,0 +1,377 @@
|
||||
|
||||
.. _developing_resource_modules:
|
||||
|
||||
***********************************
|
||||
Developing network resource modules
|
||||
***********************************
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
The resource module builder is an Ansible Playbook that helps developers scaffold and maintain an Ansible network resource module.
|
||||
|
||||
The resource module builder has the following capabilities:
|
||||
|
||||
- Uses a defined model to scaffold a resource module directory layout and initial class files.
|
||||
- Scaffolds either an Ansible role or a collection.
|
||||
- Subsequent uses of the resource module builder will only replace the module arspec and file containing the module docstring.
|
||||
- Allows you to store complex examples along side the model in the same directory.
|
||||
- Maintains the model as the source of truth for the module and use resource module builder to update the source files as needed.
|
||||
- Generates working sample modules for both ``<network_os>_<resource>`` and ``<network_os>_facts``.
|
||||
|
||||
Accessing the resource module builder
|
||||
=====================================
|
||||
|
||||
To access the resource module builder:
|
||||
|
||||
1. clone the github repository:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git clone https://github.com/ansible-network/resource_module_builder.git
|
||||
|
||||
2. Install the requirements:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install -r requirements.txt
|
||||
|
||||
Creating a model
|
||||
================
|
||||
|
||||
You must create a model for your new resource. The resource module builder uses this model to create:
|
||||
|
||||
* The scaffold for a new module
|
||||
* The argspec for the new module
|
||||
* The docstring for the new module
|
||||
|
||||
The model is then the single source of truth for both the argspec and docstring, keeping them in sync. Use the resource module builder to generate this scaffolding. For any subsequent updates to the module, update the model first and use the resource module builder to update the module argspec and docstring.
|
||||
|
||||
For example, the resource model builder includes the ``myos_interfaces.yml`` sample in the :file:`models` directory, as seen below:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
---
|
||||
GENERATOR_VERSION: '1.0'
|
||||
ANSIBLE_METADATA: |
|
||||
{
|
||||
'metadata_version': '1.1',
|
||||
'status': ['preview'],
|
||||
'supported_by': '<support_group>'
|
||||
}
|
||||
NETWORK_OS: myos
|
||||
RESOURCE: interfaces
|
||||
COPYRIGHT: Copyright 2019 Red Hat
|
||||
LICENSE: gpl-3.0.txt
|
||||
|
||||
DOCUMENTATION: |
|
||||
module: myos_interfaces
|
||||
version_added: 2.9
|
||||
short_description: 'Manages <xxxx> attributes of <network_os> <resource>'
|
||||
description: 'Manages <xxxx> attributes of <network_os> <resource>.'
|
||||
author: Ansible Network Engineer
|
||||
notes:
|
||||
- 'Tested against <network_os> <version>'
|
||||
options:
|
||||
config:
|
||||
description: The provided configuration
|
||||
type: list
|
||||
elements: dict
|
||||
suboptions:
|
||||
name:
|
||||
type: str
|
||||
description: The name of the <resource>
|
||||
some_string:
|
||||
type: str
|
||||
description:
|
||||
- The some_string_01
|
||||
choices:
|
||||
- choice_a
|
||||
- choice_b
|
||||
- choice_c
|
||||
default: choice_a
|
||||
some_bool:
|
||||
description:
|
||||
- The some_bool.
|
||||
type: bool
|
||||
some_int:
|
||||
description:
|
||||
- The some_int.
|
||||
type: int
|
||||
version_added: '1.1'
|
||||
some_dict:
|
||||
type: dict
|
||||
description:
|
||||
- The some_dict.
|
||||
suboptions:
|
||||
property_01:
|
||||
description:
|
||||
- The property_01
|
||||
type: str
|
||||
state:
|
||||
description:
|
||||
- The state of the configuration after module completion.
|
||||
type: str
|
||||
choices:
|
||||
- merged
|
||||
- replaced
|
||||
- overridden
|
||||
- deleted
|
||||
default: merged
|
||||
EXAMPLES:
|
||||
- deleted_example_01.txt
|
||||
- merged_example_01.txt
|
||||
- overridden_example_01.txt
|
||||
- replaced_example_01.txt
|
||||
|
||||
Notice that you should include examples for each of the states that the resource supports. The resource module builder also includes these in the sample model.
|
||||
|
||||
See `Ansible network resource models <https://github.com/ansible-network/resource_module_models>`_ for more examples.
|
||||
|
||||
Using the resource module builder
|
||||
=================================
|
||||
|
||||
To use the resource module builder to create a collection scaffold from your resource model:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-playbook -e rm_dest=<destination for modules and module utils> \
|
||||
-e structure=collection \
|
||||
-e collection_org=<collection_org> \
|
||||
-e collection_name=<collection_name> \
|
||||
-e model=<model> \
|
||||
site.yml
|
||||
|
||||
Where the parameters are as follows:
|
||||
|
||||
- ``rm_dest``: The directory where the resource module builder places the files and directories for the resource module and facts modules.
|
||||
- ``structure``: The directory layout type (role or collection)
|
||||
|
||||
- ``role``: Generate a role directory layout.
|
||||
- ``collection``: Generate a collection directory layout.
|
||||
|
||||
- ``collection_org``: The organization of the collection, required when `structure=collection`.
|
||||
- ``collection_name``: The name of the collection, required when `structure=collection`.
|
||||
- ``model``: The path to the model file.
|
||||
|
||||
To use the resource module builder to create a role scaffold:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-playbook -e rm_dest=<destination for modules and module utils> \
|
||||
-e structure=role \
|
||||
-e model=<model> \
|
||||
site.yml
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
Collection directory layout
|
||||
---------------------------
|
||||
|
||||
This example shows the directory layout for the following:
|
||||
|
||||
- ``network_os``: myos
|
||||
- ``resource``: interfaces
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-playbook -e rm_dest=~/github/rm_example \
|
||||
-e structure=collection \
|
||||
-e collection_org=cidrblock \
|
||||
-e collection_name=my_collection \
|
||||
-e model=models/myos/interfaces/myos_interfaces.yml \
|
||||
site.yml
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
├── docs
|
||||
├── LICENSE.txt
|
||||
├── playbooks
|
||||
├── plugins
|
||||
| ├── action
|
||||
| ├── filter
|
||||
| ├── inventory
|
||||
| ├── modules
|
||||
| | ├── __init__.py
|
||||
| | ├── myos_facts.py
|
||||
| | └── myos_interfaces.py
|
||||
| └── module_utils
|
||||
| ├── __init__.py
|
||||
| └── network
|
||||
| ├── __init__.py
|
||||
| └── myos
|
||||
| ├── argspec
|
||||
| | ├── facts
|
||||
| | | ├── facts.py
|
||||
| | | └── __init__.py
|
||||
| | ├── __init__.py
|
||||
| | └── interfaces
|
||||
| | ├── __init__.py
|
||||
| | └── interfaces.py
|
||||
| ├── config
|
||||
| | ├── __init__.py
|
||||
| | └── interfaces
|
||||
| | ├── __init__.py
|
||||
| | └── interfaces.py
|
||||
| ├── facts
|
||||
| | ├── facts.py
|
||||
| | ├── __init__.py
|
||||
| | └── interfaces
|
||||
| | ├── __init__.py
|
||||
| | └── interfaces.py
|
||||
| ├── __init__.py
|
||||
| └── utils
|
||||
| ├── __init__.py
|
||||
| └── utils.py
|
||||
├── README.md
|
||||
└── roles
|
||||
|
||||
|
||||
Role directory layout
|
||||
---------------------
|
||||
|
||||
This example displays the role directory layout for the following:
|
||||
|
||||
- ``network_os``: myos
|
||||
- ``resource``: interfaces
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-playbook -e rm_dest=~/github/rm_example/roles/my_role \
|
||||
-e structure=role \
|
||||
-e model=models/myos/interfaces/myos_interfaces.yml \
|
||||
site.yml
|
||||
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
roles
|
||||
└── my_role
|
||||
├── library
|
||||
│ ├── __init__.py
|
||||
│ ├── myos_facts.py
|
||||
│ └── myos_interfaces.py
|
||||
├── LICENSE.txt
|
||||
├── module_utils
|
||||
│ ├── __init__.py
|
||||
│ └── network
|
||||
│ ├── __init__.py
|
||||
│ └── myos
|
||||
│ ├── argspec
|
||||
│ │ ├── facts
|
||||
│ │ │ ├── facts.py
|
||||
│ │ │ └── __init__.py
|
||||
│ │ ├── __init__.py
|
||||
│ │ └── interfaces
|
||||
│ │ ├── __init__.py
|
||||
│ │ └── interfaces.py
|
||||
│ ├── config
|
||||
│ │ ├── __init__.py
|
||||
│ │ └── interfaces
|
||||
│ │ ├── __init__.py
|
||||
│ │ └── interfaces.py
|
||||
│ ├── facts
|
||||
│ │ ├── facts.py
|
||||
│ │ ├── __init__.py
|
||||
│ │ └── interfaces
|
||||
│ │ ├── __init__.py
|
||||
│ │ └── interfaces.py
|
||||
│ ├── __init__.py
|
||||
│ └── utils
|
||||
│ ├── __init__.py
|
||||
│ └── utils.py
|
||||
└── README.md
|
||||
|
||||
|
||||
Using the collection
|
||||
--------------------
|
||||
|
||||
This example shows how to use the generated collection in a playbook:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
----
|
||||
- hosts: myos101
|
||||
gather_facts: False
|
||||
tasks:
|
||||
- cidrblock.my_collection.myos_interfaces:
|
||||
register: result
|
||||
- debug:
|
||||
var: result
|
||||
- cidrblock.my_collection.myos_facts:
|
||||
- debug:
|
||||
var: ansible_network_resources
|
||||
|
||||
|
||||
Using the role
|
||||
--------------
|
||||
|
||||
This example shows how to use the generated role in a playbook:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: myos101
|
||||
gather_facts: False
|
||||
roles:
|
||||
- my_role
|
||||
|
||||
- hosts: myos101
|
||||
gather_facts: False
|
||||
tasks:
|
||||
- myos_interfaces:
|
||||
register: result
|
||||
- debug:
|
||||
var: result
|
||||
- myos_facts:
|
||||
- debug:
|
||||
var: ansible_network_resources
|
||||
|
||||
|
||||
Resource module structure and workflow
|
||||
======================================
|
||||
|
||||
The resource module structure includes the following components:
|
||||
|
||||
Module
|
||||
* ``library/<ansible_network_os>_<resource>.py``.
|
||||
* Imports the ``module_utils`` resource package and calls ``execute_module`` API
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
def main():
|
||||
result = <resource_package>(module).execute_module()
|
||||
|
||||
Module argspec
|
||||
* ``module_utils/<ansible_network_os>/argspec/<resource>/``.
|
||||
* Argspec for the resource.
|
||||
|
||||
Facts
|
||||
* ``module_utils/<ansible_network_os>/facts/<resource>/``.
|
||||
* Populate facts for the resource.
|
||||
* Entry in ``module_utils/<ansible_network_os>/facts/facts.py`` for ``get_facts`` API to keep ``<ansible_network_os>_facts`` module and facts gathered for the resource module in sync for every subset.
|
||||
* Entry of Resource subset in FACTS_RESOURCE_SUBSETS list in ``module_utils/<ansible_network_os>/facts/facts.py`` to make facts collection work.
|
||||
|
||||
Module package in module_utils
|
||||
* ``module_utils/<ansible_network_os>/<config>/<resource>/``.
|
||||
* Implement ``execute_module`` API that loads the configuration to device and generates the result with ``changed``, ``commands``, ``before`` and ``after`` keys.
|
||||
* Call ``get_facts`` API that returns the ``<resource>`` configuration facts or return the difference if the device has onbox diff support.
|
||||
* Compare facts gathered and given key-values if diff is not supported.
|
||||
* Generate final configuration.
|
||||
|
||||
Utils
|
||||
* ``module_utils/<ansible_network_os>/utils``.
|
||||
* Utilities for the ``<ansible_network_os>`` platform.
|
||||
|
||||
Developer notes
|
||||
===============
|
||||
|
||||
The tests rely on a role generated by the resource module builder. After changes to the resource module builder, the role should be regenerated and the tests modified and run as needed. To generate the role after changes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
rm -rf rmb_tests/roles/my_role
|
||||
ansible-playbook -e rm_dest=./rmb_tests/roles/my_role \
|
||||
-e structure=role \
|
||||
-e model=models/myos/interfaces/myos_interfaces.yml \
|
||||
site.yml
|
||||
@ -0,0 +1,240 @@
|
||||
|
||||
.. _collections:
|
||||
|
||||
*****************
|
||||
Using collections
|
||||
*****************
|
||||
|
||||
Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins.
|
||||
You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 2
|
||||
|
||||
Installing collections
|
||||
======================
|
||||
|
||||
You can use the ``ansible-galaxy collection install`` command to install a collection on your system. You must specify an installation location using the ``-p`` option.
|
||||
|
||||
To install a collection hosted in Galaxy:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install my_namespace.my_collection -p /collections
|
||||
|
||||
You can also directly use the tarball from your build:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections
|
||||
|
||||
.. note::
|
||||
The install command automatically appends the path ``ansible_collections`` to the one specified with the ``-p`` option unless the
|
||||
parent directory is already in a folder called ``ansible_collections``.
|
||||
|
||||
|
||||
You should use one of the values configured in :ref:`COLLECTIONS_PATHS` for your path. This is also where Ansible itself will expect to find collections when attempting to use them.
|
||||
|
||||
You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure.
|
||||
|
||||
::
|
||||
|
||||
play.yml
|
||||
├── collections/
|
||||
│ └── ansible_collections/
|
||||
│ └── my_namespace/
|
||||
│ └── my_collection/<collection structure lives here>
|
||||
|
||||
|
||||
Installing an older version of a collection
|
||||
-------------------------------------------
|
||||
|
||||
By default ``ansible-galaxy`` installs the latest collection that is available but you can add a version range
|
||||
identifier to install a specific version.
|
||||
|
||||
To install the 1.0.0 version of the collection:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install my_namespace.my_collection:1.0.0
|
||||
|
||||
To install the 1.0.0-beta.1 version of the collection:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install my_namespace.my_collection:==1.0.0-beta.1
|
||||
|
||||
To install the collections that are greater than or equal to 1.0.0 or less than 2.0.0:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install my_namespace.my_collection:>=1.0.0,<2.0.0
|
||||
|
||||
|
||||
You can specify multiple range identifiers which are split by ``,``. You can use the following range identifiers:
|
||||
|
||||
* ``*``: Any version, this is the default used when no range specified is set.
|
||||
* ``!=``: Version is not equal to the one specified.
|
||||
* ``==``: Version must be the one specified.
|
||||
* ``>=``: Version is greater than or equal to the one specified.
|
||||
* ``>``: Version is greater than the one specified.
|
||||
* ``<=``: Version is less than or equal to the one specified.
|
||||
* ``<``: Version is less than the one specified.
|
||||
|
||||
.. note::
|
||||
The ``ansible-galaxy`` command ignores any pre-release versions unless the ``==`` range identifier is used to
|
||||
explicitly set to that pre-release version.
|
||||
|
||||
|
||||
.. _collection_requirements_file:
|
||||
|
||||
Install multiple collections with a requirements file
|
||||
-----------------------------------------------------
|
||||
|
||||
You can also setup a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:
|
||||
|
||||
.. code-block:: yaml+jinja
|
||||
|
||||
---
|
||||
collections:
|
||||
# With just the collection name
|
||||
- my_namespace.my_collection
|
||||
|
||||
# With the collection name, version, and source options
|
||||
- name: my_namespace.my_other_collection
|
||||
version: 'version range identifiers (default: ``*``)'
|
||||
source: 'The Galaxy URL to pull the collection from (default: ``--api-server`` from cmdline)'
|
||||
|
||||
The ``version`` key can take in the same range identifier format documented above.
|
||||
|
||||
Roles can also be specified and placed under the ``roles`` key. The values follow the same format as a requirements
|
||||
file used in older Ansible releases.
|
||||
|
||||
.. note::
|
||||
While both roles and collections can be specified in one requirements file, they need to be installed separately.
|
||||
The ``ansible-galaxy role install -r requirements.yml`` will only install roles and
|
||||
``ansible-galaxy collection install -r requirements.yml -p ./`` will only install collections.
|
||||
|
||||
.. _galaxy_server_config:
|
||||
|
||||
Galaxy server configuration list
|
||||
--------------------------------
|
||||
|
||||
By default running ``ansible-galaxy`` will use the :ref:`galaxy_server` config value or the ``--server`` command line
|
||||
argument when it performs an action against a Galaxy server. The ``ansible-galaxy collection install`` supports
|
||||
installing collections from multiple servers as defined in the :ref:`ansible_configuration_settings_locations` file
|
||||
using the :ref:`galaxy_server_list` configuration option. To define multiple Galaxy servers you have to create the
|
||||
following entries like so:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[galaxy]
|
||||
server_list = my_org_hub, release_galaxy, test_galaxy
|
||||
|
||||
[galaxy_server.my_org_hub]
|
||||
url=https://automation.my_org/
|
||||
username=my_user
|
||||
password=my_pass
|
||||
|
||||
[galaxy_server.release_galaxy]
|
||||
url=https://galaxy.ansible.com/
|
||||
token=my_token
|
||||
|
||||
[galaxy_server.test_galaxy]
|
||||
url=https://galaxy-dev.ansible.com/
|
||||
token=my_token
|
||||
|
||||
.. note::
|
||||
You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and
|
||||
the value of this arg should match the name of the server. If the value of ``--server`` is not a pre-defined server
|
||||
in ``ansible.cfg`` then the value specified will be the URL used to access that server and all pre-defined servers
|
||||
are ignored. Also the ``--api-key`` argument is not applied to any of the pre-defined servers, it is only applied
|
||||
if no server list is defined or a URL was specified by ``--server``.
|
||||
|
||||
|
||||
The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a
|
||||
collection, the install process will search in that order, e.g. ``my_org_hub`` first, then ``release_galaxy``, and
|
||||
finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section
|
||||
``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then
|
||||
define the following keys:
|
||||
|
||||
* ``url``: The URL of the galaxy instance to connect to, this is required.
|
||||
* ``token``: A token key to use for authentication against the Galaxy instance, this is mutually exclusive with ``username``
|
||||
* ``username``: The username to use for basic authentication against the Galaxy instance, this is mutually exclusive with ``token``
|
||||
* ``password``: The password to use for basic authentication
|
||||
|
||||
As well as being defined in the ``ansible.cfg`` file, these server options can be defined as an environment variable.
|
||||
The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper
|
||||
case form of the server identifier and ``{{ key }}`` is the key to define. For example I can define ``token`` for
|
||||
``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``.
|
||||
|
||||
For operations where only one Galaxy server is used, i.e. ``publish``, ``info``, ``login`` then the first entry in the
|
||||
``server_list`` is used unless an explicit server was passed in as a command line argument.
|
||||
|
||||
.. note::
|
||||
Once a collection is found, any of its requirements are only searched within the same Galaxy instance as the parent
|
||||
collection. The install process will not search for a collection requirement in a different Galaxy instance.
|
||||
|
||||
|
||||
.. _using_collections:
|
||||
|
||||
Using collections in a Playbook
|
||||
===============================
|
||||
|
||||
Once installed, you can reference a collection content by its fully qualified collection name (FQCN):
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: all
|
||||
tasks:
|
||||
- my_namespace.my_collection.mymodule:
|
||||
option1: value
|
||||
|
||||
This works for roles or any type of plugin distributed within the collection:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: all
|
||||
tasks:
|
||||
- import_role:
|
||||
name: my_namespace.my_collection.role1
|
||||
|
||||
- my_namespace.mycollection.mymodule:
|
||||
option1: value
|
||||
|
||||
- debug:
|
||||
msg: '{{ lookup("my_namespace.my_collection.lookup1", 'param1')| my_namespace.my_collection.filter1 }}'
|
||||
|
||||
|
||||
To avoid a lot of typing, you can use the ``collections`` keyword added in Ansible 2.8:
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: all
|
||||
collections:
|
||||
- my_namespace.my_collection
|
||||
tasks:
|
||||
- import_role:
|
||||
name: role1
|
||||
|
||||
- mymodule:
|
||||
option1: value
|
||||
|
||||
- debug:
|
||||
msg: '{{ lookup("my_namespace.my_collection.lookup1", 'param1')| my_namespace.my_collection.filter1 }}'
|
||||
|
||||
This keyword creates a 'search path' for non namespaced plugin references. It does not import roles or anything else.
|
||||
Notice that you still need the FQCN for non-action or module plugins.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:ref:`developing_collections`
|
||||
Develop or modify a collection.
|
||||
:ref:`collections_galaxy_meta`
|
||||
Understand the collections metadata structure.
|
||||
`Mailing List <https://groups.google.com/group/ansible-devel>`_
|
||||
The development mailing list
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
#ansible IRC chat channel
|
||||
Loading…
Reference in New Issue