@@ -31,29 +31,22 @@ docs/man/man3/*

 # docsite stuff...

 docs/api/_build/

 docs/api/rst/

-docs/docsite/*.html

 docs/docsite/_build

-docs/docsite/_static/*.gif

-docs/docsite/_static/*.png

-docs/docsite/_static/websupport.js

+docs/docsite/*.html

 docs/docsite/htmlout

-docs/docsite/searchindex.js

-docs/docsite/rst_warnings

-docs/docsite/rst/*_module.rst

-docs/docsite/rst/ansible.rst

-docs/docsite/rst/ansible-*.rst

-docs/docsite/rst/community_maintained.rst

-docs/docsite/rst/config.rst

-docs/docsite/rst/core_maintained.rst

-docs/docsite/rst/list_of_*.rst

-docs/docsite/rst/module_docs/*.rst

-docs/docsite/rst/modules_by_category.rst

-docs/docsite/rst/network_maintained.rst

-docs/docsite/rst/plugins_by_category.rst

-docs/docsite/rst/partner_maintained.rst

-docs/docsite/rst/playbooks_keywords.rst

+docs/docsite/rst/cli/ansible-*.rst

+docs/docsite/rst/cli/ansible.rst

+docs/docsite/rst/modules/*.rst

 docs/docsite/rst/playbooks_directives.rst

+docs/docsite/rst/plugins_by_category.rst

 docs/docsite/rst/plugins/*/*.rst

+docs/docsite/rst/reference_appendices/config.rst

+docs/docsite/rst/reference_appendices/playbooks_keywords.rst

+docs/docsite/rst_warnings

+docs/docsite/searchindex.js

+docs/docsite/_static/*.gif

+docs/docsite/_static/*.png

+docs/docsite/_static/websupport.js

 # deb building stuff...

 /debian/

 deb-build

@@ -58,19 +58,19 @@ clean:

 	find . -type f \( -name "*~" -or -name "#*" \) -delete

 	find . -type f \( -name "*.swp" \) -delete

 	@echo "Cleaning up generated rst"

-	-rm rst/list_of_*.rst

-	-rm rst/*_by_category.rst

-	-rm rst/*_module.rst

-	-rm rst/*_plugin.rst

-	-rm rst/*_maintained.rst

+	-rm rst/cli/ansible-*.rst

+	-rm rst/cli/ansible.rst

+	-rm rst/modules/*_by_category.rst

+	-rm rst/modules/list_of_*.rst

+	-rm rst/modules/*_maintained.rst

+	-rm rst/modules/*_module.rst

+	-rm rst/modules/*_plugin.rst

 	-rm rst/playbooks_directives.rst

-	-rm rst/playbooks_keywords.rst

 	-rm rst/plugins/*/*.rst

-	-rm rst/config.rst

-	-rm rst/ansible-*.rst

-	-rm rst/ansible.rst

+	-rm rst/reference_appendices/config.rst

+	-rm rst/reference_appendices/playbooks_keywords.rst

-.PHONEY: docs clean

+.PHONY: docs clean

 # TODO: make generate_man output dir cli option

 cli: $(GENERATE_CLI)

deleted file mode 100644

@@ -1,392 +0,0 @@

-Getting started with Cisco ACI

-==============================

-

-.. contents:: Topics

-   :depth: 2

-   :local:

-

-.. _aci_intro:

-

-What is Cisco ACI ?

-

-Application Centric Infrastructure (ACI)

-........................................

-The Cisco Application Centric Infrastructure (ACI) allows application requirements to define the network. This architecture simplifies, optimizes, and accelerates the entire application deployment life cycle.

-

-Application Policy Infrastructure Controller (APIC)

-...................................................

-The Cisco Application Policy Infrastructure Controller (APIC) API enables applications to directly connect with a secure, shared, high-performance resource pool that includes network, compute, and storage capabilities.

-

-The APIC manages the scalable ACI multi-tenant fabric. The APIC provides a unified point of automation and management, policy programming, application deployment, and health monitoring for the fabric. The APIC, which is implemented as a replicated synchronized clustered controller, optimizes performance, supports any application anywhere, and provides unified operation of the physical and virtual infrastructure.

-

-The APIC enables network administrators to easily define the optimal network for applications. Data center operators can clearly see how applications consume network resources, easily isolate and troubleshoot application and infrastructure problems, and monitor and profile resource usage patterns.

-

-ACI Fabric

-..........

-The Cisco Application Centric Infrastructure (ACI) Fabric includes Cisco Nexus 9000 Series switches with the APIC to run in the leaf/spine ACI fabric mode. These switches form a "fat-tree" network by connecting each leaf node to each spine node; all other devices connect to the leaf nodes. The APIC manages the ACI fabric.

-

-The ACI fabric provides consistent low-latency forwarding across high-bandwidth links (40 Gbps, with a 100-Gbps future capability). Traffic with the source and destination on the same leaf switch is handled locally, and all other traffic travels from the ingress leaf to the egress leaf through a spine switch. Although this architecture appears as two hops from a physical perspective, it is actually a single Layer 3 hop because the fabric operates as a single Layer 3 switch.

-

-The ACI fabric object-oriented operating system (OS) runs on each Cisco Nexus 9000 Series node. It enables programming of objects for each configurable element of the system. The ACI fabric OS renders policies from the APIC into a concrete model that runs in the physical infrastructure. The concrete model is analogous to compiled software; it is the form of the model that the switch operating system can execute.

-

-All the switch nodes contain a complete copy of the concrete model. When an administrator creates a policy in the APIC that represents a configuration, the APIC updates the logical model. The APIC then performs the intermediate step of creating a fully elaborated policy that it pushes into all the switch nodes where the concrete model is updated.

-

-The APIC is responsible for fabric activation, switch firmware management, network policy configuration, and instantiation. While the APIC acts as the centralized policy and network management engine for the fabric, it is completely removed from the data path, including the forwarding topology. Therefore, the fabric can still forward traffic even when communication with the APIC is lost.

-

-More information

-................

-Various resources exist to start learning ACI, here is a list of interesting articles from the community.

-

-- `Adam Raffe: Learning ACI <https://adamraffe.com/learning-aci/>`_

-- `Luca Relandini: ACI for dummies <http://lucarelandini.blogspot.be/2015/03/aci-for-dummies.html>`_

-- `Cisco DevNet Learning Labs about ACI <https://learninglabs.cisco.com/labs/tags/ACI>`_

-

-

-Using the ACI modules

-The Ansible ACI modules provide a user-friendly interface to managing your ACI environment using Ansible playbooks.

-

-For instance ensuring that a specific tenant exists, is done using the following Ansible task:

-

-.. code-block:: yaml

-

-    - name: Ensure tenant customer-xyz exists

-      aci_tenant:

-        host: my-apic-1

-        username: admin

-        password: my-password

-    

-        tenant: customer-xyz

-        description: Customer XYZ

-        state: present

-

-A complete list of existing ACI modules is available for `the latest stable release <http://docs.ansible.com/ansible/latest/list_of_network_modules.html#aci>`_ as well as `the current development version <http://docs.ansible.com/ansible/devel/module_docs/list_of_network_modules.html#aci>`_.

-

-Standard module parameters

-..........................

-Every Ansible ACI module accepts the following parameters that influence the module's communication with the APIC REST API:

-

-- ``host`` -- Hostname or IP address of the APIC

-- ``port`` -- Port to use for communication (defaults to ``443`` for HTTPS, and ``80`` for HTTP)

-- ``username`` -- User name used to log on to the APIC (defaults to ``admin``)

-- ``password`` -- Password for ``username`` to log on to the APIC (using password-based authentication)

-- ``private_key`` -- Private key for ``username`` to log on to APIC (using signature-based authentication)

-- ``certificate_name`` -- Name of the certificate in the ACI Web GUI (defaults to ``private_key`` file base name)

-- ``timeout`` -- Timeout value for socket-level communication

-- ``use_proxy`` -- Use system proxy settings (defaults to ``yes``)

-- ``use_ssl`` -- Use HTTPS or HTTP for APIC REST communication (defaults to ``yes``)

-- ``validate_certs`` -- Validate certificate when using HTTPS communication (defaults to ``yes``)

-- ``output_level`` -- Influence the level of detail ACI modules return to the user (one of ``normal``, ``info`` or ``debug``)

-

-Module return values

-....................

-By default the ACI modules (excluding :ref:`aci_rest <aci_rest>`) return the resulting state of the managed object in a key ``current``.

-

-By increasing the ``output_level`` to ``info``, the modules give access to the ``previous`` state of the object, but also the ``proposed`` and ``sent`` configuration payload.

-

-For troubleshooting purposes setting ``output_level: debug`` or defining environment variable ``ANSIBLE_DEBUG=1`` enables more detailed information on the actual APIC REST communication, incl. ``filter_string``, ``method``, ``response``, ``status`` and ``url``.

-

-.. note:: The module return values are documented in detail as part of each module's documentation.

-

-More information

-................

-Various resources exist to start learn more about ACI programmability, we recommend the following links:

-

-- `Jacob McGill: Automating Cisco ACI with Ansible <https://blogs.cisco.com/developer/automating-cisco-aci-with-ansible-eliminates-repetitive-day-to-day-tasks>`_

-- `Cisco DevNet Learning Labs about ACI and Ansible <https://learninglabs.cisco.com/labs/tags/ACI,Ansible>`_

-

-

-.. _aci_auth:

-

-ACI authentication

-

-Password-based authentication

-.............................

-If you want to logon using a username and password, you can use the following parameters with your ACI modules:

-

-.. code-block:: yaml

-

-    username: admin

-    password: my-password

-

-Password-based authentication is very simple to work with, but it is not the most efficient form of authentication from ACI's point-of-view as it requires a separate login-request and an open session to work. To avoid having your session time-out and requiring another login, you can use the more efficient Signature-based authentication.

-

-.. note:: Password-based authentication also may trigger anti-DoS measures in ACI v3.1+ that causes session throttling and results in HTTP 503 errors and login failures.

-

-.. warning:: Never store passwords in plain text.

-

-The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :doc:`playbooks_vault` for more information.

-

-

-

-Signature-based authentication using certificates

-.................................................

-Using signature-based authentication is more efficient and more reliable than password-based authentication.

-

-Generate certificate and private key

-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

-Signature-based authentication requires a (self-signed) X.509 certificate with private key, and a configuration step for your AAA user in ACI. To generate a working X.509 certificate and private key, use the following procedure:

-

-.. code-block:: bash

-

-    $ openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout admin.key -out admin.crt -subj '/CN=Admin/O=Your Company/C=US'

-

-Configure your local user

-,,,,,,,,,,,,,,,,,,,,,,,,,

-Perform the following steps:

-

-- Add the X.509 certificate to your ACI AAA local user at **ADMIN > AAA**

-- Click **AAA Authentication**

-- Check that in the **Authentication** field the **Realm** field displays **Local**

-- Expand **Security Management > Local Users**

-- Click the name of the user you want to add a certificate to, in the **User Certificates** area

-- Click the **+** sign and in the **Create X509 Certificate** enter a certificate name in the **Name** field

-

-  * If you use the basename of your private key here, you don't need to enter ``certificate_name`` in Ansible

-

-- Copy and paste your X.509 certificate in the **Data** field.

-

-You can automate this by using the following Ansible task:

-

-.. code-block:: yaml

-

-    - name: Ensure we have a certificate installed

-      aci_aaa_user_certificate:

-        host: my-apic-1

-        username: admin

-        password: my-password

-    

-        aaa_user: admin

-        certificate_name: admin

-        certificate: "{{ lookup('file', 'pki/admin.crt') }}"  # This wil read the certificate data from a local file

-

-.. note:: Signature-based authentication only works with local users.

-

-

-Use signature-based authentication with Ansible

-,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

-You need the following parameters with your ACI module(s) for it to work:

-

-.. code-block:: yaml

-

-    username: admin

-    private_key: pki/admin.key

-    certificate_name: admin  # This could be left out !

-

-.. note:: If you use a certificate name in ACI that matches the private key's basename, you can leave out the ``certificate_name`` parameter like the example above.

-

-More information

-,,,,,,,,,,,,,,,,

-More information about Signature-based Authentication is available from `Cisco APIC Signature-Based Transactions <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_KB_Signature_Based_Transactions.html>`_.

-

-

-.. _aci_rest:

-

-Using ACI REST with Ansible

-While already a lot of ACI modules exists in the Ansible distribution, and the most common actions can be performed with these existing modules, there's always something that may not be possible with off-the-shelf modules.

-

-The :ref:`aci_rest <aci_rest>` module provides you with direct access to the APIC REST API and enables you to perform any task not already covered by the existing modules. This may seem like a complex undertaking, but you can generate the needed REST payload for any action performed in the ACI web interface effortlessly.

-

-Using the aci-rest module

-.........................

-The :ref:`aci_rest <aci_rest>` module accepts the native XML and JSON payloads, but additionally accepts inline YAML payload (structured like JSON). The XML payload requires you to use a path ending with ``.xml`` whereas JSON or YAML require path to end with ``.json``.

-

-When you're making modifications, you can use the POST or DELETE methods, whereas doing just queries require the GET method.

-

-For instance, if you would like to ensure a specific tenant exists on ACI, these below four examples are identical:

-

-**XML** (Native ACI)

-

-.. code-block:: yaml

-

-    - aci_rest:

-        host: my-apic-1

-        private_key: pki/admin.key

-    

-        method: post

-        path: /api/mo/uni.xml

-        content: |

-          <fvTenant name="customer-xyz" descr="Customer XYZ"/>

-

-**JSON** (Native ACI)

-

-.. code-block:: yaml

-

-    - aci_rest:

-        host: my-apic-1

-        private_key: pki/admin.key

-    

-        method: post

-        path: /api/mo/uni.json

-        content:

-          {

-            "fvTenant": {

-              "attributes": {

-                "name": "customer-xyz",

-                "descr": "Customer XYZ"

-              }

-            }

-          }

-

-**YAML** (Ansible-style)

-

-.. code-block:: yaml

-

-    - aci_rest:

-        host: my-apic-1

-        private_key: pki/admin.key

-    

-        method: post

-        path: /api/mo/uni.json

-        content:

-          fvTenant:

-            attributes:

-              name: customer-xyz

-              descr: Customer XYZ

-

-**Ansible task** (Dedicated module)

-

-.. code-block:: yaml

-

-    - aci_tenant:

-        host: my-apic-1

-        private_key: pki/admin.key

-    

-        tenant: customer-xyz

-        description: Customer XYZ

-        state: present

-

-More information

-................

-Plenty of resources exist to learn about ACI's APIC REST interface, we recommend the links below:

-

-- `The apic_rest Ansible module <http://docs.ansible.com/ansible/devel/module_docs/aci_rest_module.html>`_

-- `APIC REST API Configuration Guide <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/rest_cfg/2_1_x/b_Cisco_APIC_REST_API_Configuration_Guide.html>`_

-- `Cisco DevNet Learning Labs about ACI and REST <https://learninglabs.cisco.com/labs/tags/ACI,REST>`_

-

-

-.. _aci_ops:

-

-Operational examples

-Here is a small overview of useful operational tasks to reuse in your playbooks.

-Feel free to contribute more snippets that are useful to others.

-

-Waiting for all controllers to be ready

-.......................................

-You can use the below task after you started to build your APICs and configured the cluster to wait until all the APICs have come online. It will wait until the number of controllers equals the number listed in the ``apic`` inventory group.

-

-.. code-block:: yaml

-

-    - name: Waiting for all controllers to be ready

-      aci_rest:

-        host: '{{ apic_ip }}'

-        username: '{{ apic_username }}'

-        private_key: pki/admin.key

-        method: get

-        path: /api/node/class/topSystem.json?query-target-filter=eq(topSystem.role,"controller")

-      changed_when: no

-      register: aci_ready

-      until: aci_ready|success and aci_ready.totalCount|int >= groups['apic']|count

-      retries: 20

-      delay: 30

-

-Waiting for cluster to be fully-fit

-...................................

-The below example waits until the cluster is fully-fit. In this example you know the number of APICs in the cluster and you verify each APIC reports a 'fully-fit' status.

-

-.. code-block:: yaml

-

-    - name: Waiting for cluster to be fully-fit

-      aci_rest:

-        host: '{{ apic_ip }}'

-        username: '{{ apic_username }}'

-        private_key: pki/admin.key

-        method: get

-        path: /api/node/class/infraWiNode.json?query-target-filter=wcard(infraWiNode.dn,"topology/pod-1/node-1/av")

-      changed_when: no

-      register: aci_fit

-      until: >

-        aci_fit|success and

-        aci_fit.totalCount|int >= groups['apic']|count >= 3 and

-        aci_fit.imdata[0].infraWiNode.attributes.health == 'fully-fit' and

-        aci_fit.imdata[1].infraWiNode.attributes.health == 'fully-fit' and

-        aci_fit.imdata[2].infraWiNode.attributes.health == 'fully-fit'

-    #    all(apic.infraWiNode.attributes.health == 'fully-fit' for apic in aci_fit.imdata)

-      retries: 30

-      delay: 30

-

-

-.. _aci_errors:

-

-APIC error messages

-The following error messages may occur and this section can help you understand what exactly is going on.

-

-- **APIC Error 122: unknown managed object class 'polUni'**

-

-  In case you receive this error while you are certain your :ref:`aci_rest <aci_rest>` payload and object classes are seemingly correct, the issue might be that your payload is not in fact correct JSON (e.g. the sent payload is using single quotes, rather than double quotes), and as a result the APIC is not correctly parsing your object classes from the payload. One way to avoid this is by using a YAML or an XML formatted payload.

-

-

-- **APIC Error 400: invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag**

-

-  While JSON does not care about the order of dictionary keys, the APIC is very strict in accepting only ``attributes`` before ``children``. So you need to ensure that your payload conforms to this requirement. Sorting your dictionary keys will do the trick just fine.

-

-

-- **APIC Error 801: property descr of uni/tn-TENANT/ap-AP failed validation for value 'A "legacy" network'**

-

-  Some values in the APIC have strict format-rules to comply to, and the internal APIC validation check for the provided value failed. In the above case, the ``description`` parameter (internally known as ``descr``) only accepts values conforming to `Regex: [a-zA-Z0-9\\!#$%()*,-./:;@ _{|}~?&+]+ <https://pubhub-prod.s3.amazonaws.com/media/apic-mim-ref/docs/MO-fvAp.html#descr>`_ so it must not include quotes.

-

-

-.. _aci_issues:

-

-Known issues

-The :ref:`aci_rest <aci_rest>` module is a wrapper around the APIC REST API. As a result any issues related to the APIC will be reflected in the use of the :ref:`aci_rest <aci_rest>` module.

-

-All below issues either have been reported to the vendor, or can simply be avoided.

-

-- **Too many consecutive API calls may result in connection throttling**

-

-  Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific treshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this treshold within the nginx configuration, but using signature-based authentication is recommended.

-

-  **NOTE:** It is advisable to use signature-based authentication with ACI as it not only prevents connection-throttling, but also improves general performance when using the ACI modules.

-

-

-- **Specific requests may not reflect changes correctly**

-

-  There is a known issue where specific requests to the APIC do not properly reflect changed in the resulting output, even when we request those changes explicitly from the APIC. In one instance using the path ``api/node/mo/uni/infra.xml`` fails, where ``api/node/mo/uni/infra/.xml`` does work correctly.

-

-  More information from: `#35401 aci_rest: change not detected <https://github.com/ansible/ansible/issues/35041>`_

-

-  **NOTE:** Fortunately the behaviour is consistent, so if you have a working example you can trust that it will keep on working.

-

-

-- **Specific requests are known to not be idempotent**

-

-  The behaviour of the APIC is inconsistent to the use of ``status="created"`` and ``status="deleted"``. The result is that when you use ``status="created"`` in your payload the resulting tasks are not idempotent and creation will fail when the object was already created. However this is not the case with ``status="deleted"`` where such call to an non-existing object does not cause any failure whatsoever.

-

-  More information from: `#35050 aci_rest: Using status="created" behaves differently than status="deleted" <https://github.com/ansible/ansible/issues/35050>`_

-

-  **NOTE:** A workaround is to avoid using ``status="created"`` and instead use ``status="modified"`` when idempotency is essential to your workflow..

-

-

-- **Setting user password is not idempotent**

-

-  Due to an inconsistency in the APIC REST API, a task that sets the password of a locally-authenticated user is not idempotent. The APIC will complain with message ``Password history check: user dag should not use previous 5 passwords``.

-

-  More information from: `#35544 aci_aaa_user: Setting user password is not idempotent <https://github.com/ansible/ansible/issues/35544>`_

-

-  **NOTE:** There is no workaround for this issue.

-

-

-.. _aci_community:

-

-ACI Ansible community

-If you have specific issues with the ACI modules, or a feature request, or you like to contribute to the ACI project by proposing changes or documentation updates, look at the Ansible Community wiki ACI page at: https://github.com/ansible/community/wiki/Network:-ACI

-

-You will find our roadmap, an overview of open ACI issues and pull-requests and more information about who we are. If you have an interest in using ACI with Ansible, feel free to join ! We occasionally meet online to track progress and prepare for new Ansible releases.

@@ -50,7 +50,6 @@ Ansible, Inc. releases a new major release of Ansible approximately every two mo

    :caption: Scenario Guides

    networking_guide/network

-   ..scenario_guides/guides

    scenario_guides/guide_aws

    scenario_guides/guide_azure

    scenario_guides/guide_rax

@@ -65,7 +64,7 @@ Ansible, Inc. releases a new major release of Ansible approximately every two mo

    :maxdepth: 2

    :caption: Reference & Appendices

-   reference_appendices/modules_by_category

+   ../modules/modules_by_category

    reference_appendices/playbooks_keywords

    reference_appendices/galaxy

    reference_appendices/common_return_values

deleted file mode 100644

@@ -1,3021 +0,0 @@

-==============================

-Ansible Configuration Settings

-==============================

-

-Ansible supports a few ways of providing configuration variables, mainly through environment variables, command line switches and an ini file named ``ansible.cfg``.

-

-Starting at Ansible 2.4 the ``ansible-config`` utility allows users to see all the configuration settings available, their defaults, how to set them and

-where their current value comes from. See :doc:ansible-config for more information.

-

-

-The configuration file

-======================

-

-Changes can be made and used in a configuration file which will be searched for in the following order:

-

- * ``ANSIBLE_CONFIG`` (environment variable if set)

- * ``ansible.cfg`` (in the current directory)

- * ``~/.ansible.cfg`` (in the home directory)

- * ``/etc/ansible/ansible.cfg``

-

-Ansible will process the above list and use the first file found, all others are ignored.

-

-.. note::

-

-   The configuration file is one variant of an INI format.

-   Both the hash sign (``#``) and semicolon (``;``) are allowed as

-   comment markers when the comment starts the line.

-   However, if the comment is inline with regular values,

-   only the semicolon is allowed to introduce the comment.

-   For instance::

-

-        # some basic default values...

-        inventory = /etc/ansible/hosts  ; This points to the file that lists your hosts

-

-

-Common Options

-==============

-

-This is a copy of the options available from our release, your local install might have extra options due to additional plugins,

-you can use the command line utility mentioned above (`ansible-config`) to browse through those.

-

-

-

-.. _ACTION_WARNINGS:

-

-ACTION_WARNINGS

-

-:Description: By default Ansible will issue a warning when recieved from a task action (module or action plugin) These warnings can be silenced by adjusting this setting to False.

-:Type: boolean

-:Default: True

-:Version Added: 2.5

-:Ini Section: defaults

-:Ini Key: action_warnings

-:Environment: :envvar:`ANSIBLE_ACTION_WARNINGS`

-

-.. _AGNOSTIC_BECOME_PROMPT:

-

-AGNOSTIC_BECOME_PROMPT

-

-:Description: Display an agnostic become prompt instead of displaying a prompt containing the command line supplied become method

-:Type: boolean

-:Default: False

-:Version Added: 2.5

-:Ini Section: privilege_escalation

-:Ini Key: agnostic_become_prompt

-:Environment: :envvar:`ANSIBLE_AGNOSTIC_BECOME_PROMPT`

-

-.. _ALLOW_WORLD_READABLE_TMPFILES:

-

-ALLOW_WORLD_READABLE_TMPFILES

-

-:Description: This makes the temporary files created on the machine to be world readable and will issue a warning instead of failing the task. It is useful when becoming an unprivileged user.

-:Type: boolean

-:Default: False

-:Version Added: 2.1

-:Ini Section: defaults

-:Ini Key: allow_world_readable_tmpfiles

-

-.. _ANSIBLE_COW_PATH:

-

-ANSIBLE_COW_PATH

-

-:Description: Specify a custom cowsay path or swap in your cowsay implementation of choice

-:Type: string

-:Default: None

-:Ini Section: defaults

-:Ini Key: cowpath

-:Environment: :envvar:`ANSIBLE_COW_PATH`

-

-.. _ANSIBLE_COW_SELECTION:

-

-ANSIBLE_COW_SELECTION

-

-:Description: This allows you to chose a specific cowsay stencil for the banners or use 'random' to cycle through them.

-:Default: default

-:Ini Section: defaults

-:Ini Key: cow_selection

-:Environment: :envvar:`ANSIBLE_COW_SELECTION`

-

-.. _ANSIBLE_COW_WHITELIST:

-

-ANSIBLE_COW_WHITELIST

-

-:Description: White list of cowsay templates that are 'safe' to use, set to empty list if you want to enable all installed templates.

-:Type: list

-:Default: ['bud-frogs', 'bunny', 'cheese', 'daemon', 'default', 'dragon', 'elephant-in-snake', 'elephant', 'eyes', 'hellokitty', 'kitty', 'luke-koala', 'meow', 'milk', 'moofasa', 'moose', 'ren', 'sheep', 'small', 'stegosaurus', 'stimpy', 'supermilker', 'three-eyes', 'turkey', 'turtle', 'tux', 'udder', 'vader-koala', 'vader', 'www']

-:Ini Section: defaults

-:Ini Key: cow_whitelist

-:Environment: :envvar:`ANSIBLE_COW_WHITELIST`

-

-.. _ANSIBLE_FORCE_COLOR:

-

-ANSIBLE_FORCE_COLOR

-

-:Description: This options forces color mode even when running without a TTY or the "nocolor" setting is True.

-:Type: boolean

-:Default: False

-:Ini Section: defaults

-:Ini Key: force_color

-:Environment: :envvar:`ANSIBLE_FORCE_COLOR`

-

-.. _ANSIBLE_NOCOLOR:

-

-ANSIBLE_NOCOLOR

-

-:Description: This setting allows suppressing colorizing output, which is used to give a better indication of failure and status information.

-:Type: boolean

-:Default: False

-:Ini Section: defaults

-:Ini Key: nocolor

-:Environment: :envvar:`ANSIBLE_NOCOLOR`

-

-.. _ANSIBLE_NOCOWS:

-

-ANSIBLE_NOCOWS

-

-:Description: If you have cowsay installed but want to avoid the 'cows' (why????), use this.

-:Type: boolean

-:Default: False

-:Ini Section: defaults

-:Ini Key: nocows

-:Environment: :envvar:`ANSIBLE_NOCOWS`

-

-.. _ANSIBLE_PIPELINING:

-

-ANSIBLE_PIPELINING

-

-:Description: Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer. This can result in a very significant performance improvement when enabled. However this conflicts with privilege escalation (become). For example, when using 'sudo:' operations you must first disable 'requiretty' in /etc/sudoers on all managed hosts, which is why it is disabled by default.

-:Type: boolean

-:Default: False

-:Ini Section: connection

-:Ini Key: pipelining

-:Ini Section: ssh_connection

-:Ini Key: pipelining

-:Environment: :envvar:`ANSIBLE_PIPELINING`

-:Environment: :envvar:`ANSIBLE_SSH_PIPELINING`

-

-.. _ANSIBLE_SSH_ARGS:

-

-ANSIBLE_SSH_ARGS

-

-:Description: If set, this will override the Ansible default ssh arguments. In particular, users may wish to raise the ControlPersist time to encourage performance.  A value of 30 minutes may be appropriate. Be aware that if `-o ControlPath` is set in ssh_args, the control path setting is not used.

-:Default: -C -o ControlMaster=auto -o ControlPersist=60s

-:Ini Section: ssh_connection

-:Ini Key: ssh_args

-:Environment: :envvar:`ANSIBLE_SSH_ARGS`

-

-.. _ANSIBLE_SSH_CONTROL_PATH:

-

-ANSIBLE_SSH_CONTROL_PATH

-

-:Description: This is the location to save ssh's ControlPath sockets, it uses ssh's variable substitution. Since 2.3, if null, ansible will generate a unique hash. Use `%(directory)s` to indicate where to use the control dir path setting. Before 2.3 it defaulted to `control_path=%(directory)s/ansible-ssh-%%h-%%p-%%r`. Be aware that this setting is ignored if `-o ControlPath` is set in ssh args.

-:Default: None

-:Ini Section: ssh_connection

-:Ini Key: control_path

-:Environment: :envvar:`ANSIBLE_SSH_CONTROL_PATH`

-

-.. _ANSIBLE_SSH_CONTROL_PATH_DIR:

-

-ANSIBLE_SSH_CONTROL_PATH_DIR

-

-:Description: This sets the directory to use for ssh control path if the control path setting is null. Also, provides the `%(directory)s` variable for the control path setting.

-:Default: ~/.ansible/cp

-:Ini Section: ssh_connection

-:Ini Key: control_path_dir

-:Environment: :envvar:`ANSIBLE_SSH_CONTROL_PATH_DIR`

-

-.. _ANSIBLE_SSH_EXECUTABLE:

-

-ANSIBLE_SSH_EXECUTABLE

-

-:Description: This defines the location of the ssh binary. It defaults to `ssh` which will use the first ssh binary available in $PATH. This option is usually not required, it might be useful when access to system ssh is restricted, or when using ssh wrappers to connect to remote hosts.

-:Default: ssh

-:Version Added: 2.2

-:Ini Section: ssh_connection

-:Ini Key: ssh_executable

-:Environment: :envvar:`ANSIBLE_SSH_EXECUTABLE`

-

-.. _ANSIBLE_SSH_RETRIES:

-

-ANSIBLE_SSH_RETRIES

-

-:Description: Number of attempts to establish a connection before we give up and report the host as 'UNREACHABLE'

-:Type: integer

-:Default: 0

-:Ini Section: ssh_connection

-:Ini Key: retries

-:Environment: :envvar:`ANSIBLE_SSH_RETRIES`

-

-.. _ANY_ERRORS_FATAL:

-

-ANY_ERRORS_FATAL

-

-:Description: Sets the default value for the any_errors_fatal keyword, if True, Task failures will be considered fatal errors.

-:Type: boolean

-:Default: False

-:Version Added: 2.4

-:Ini Section: defaults

-:Ini Key: any_errors_fatal

-:Environment: :envvar:`ANSIBLE_ANY_ERRORS_FATAL`

-

-.. _BECOME_ALLOW_SAME_USER:

-

-BECOME_ALLOW_SAME_USER

-

-:Description: This setting controls if become is skipped when remote user and become user are the same. I.E root sudo to root.

-:Type: boolean

-:Default: False

-:Ini Section: privilege_escalation

-:Ini Key: become_allow_same_user

-:Environment: :envvar:`ANSIBLE_BECOME_ALLOW_SAME_USER`

-

-.. _CACHE_PLUGIN:

-

-CACHE_PLUGIN

-

-:Description: Chooses which cache plugin to use, the default 'memory' is ephimeral.

-:Default: memory

-:Ini Section: defaults

-:Ini Key: fact_caching

-:Environment: :envvar:`ANSIBLE_CACHE_PLUGIN`

-

-.. _CACHE_PLUGIN_CONNECTION:

-

-CACHE_PLUGIN_CONNECTION

-

-:Description: Defines connection or path information for the cache plugin

-:Default: None

-:Ini Section: defaults

-:Ini Key: fact_caching_connection

-:Environment: :envvar:`ANSIBLE_CACHE_PLUGIN_CONNECTION`

-

-.. _CACHE_PLUGIN_PREFIX:

-

-CACHE_PLUGIN_PREFIX

-

-:Description: Prefix to use for cache plugin files/tables

-:Default: ansible_facts

-:Ini Section: defaults

-:Ini Key: fact_caching_prefix

-:Environment: :envvar:`ANSIBLE_CACHE_PLUGIN_PREFIX`

-

-.. _CACHE_PLUGIN_TIMEOUT:

-

-CACHE_PLUGIN_TIMEOUT

-

-:Description: Expiration timeout for the cache plugin data

-:Type: integer

-:Default: 86400

-:Ini Section: defaults

-:Ini Key: fact_caching_timeout

-:Environment: :envvar:`ANSIBLE_CACHE_PLUGIN_TIMEOUT`

-

-.. _COLOR_CHANGED:

-

-COLOR_CHANGED

-

-:Description: Defines the color to use on 'Changed' task status

-:Default: yellow

-:Ini Section: colors

-:Ini Key: changed

-:Environment: :envvar:`ANSIBLE_COLOR_CHANGED`

-

-.. _COLOR_DEBUG:

-

-COLOR_DEBUG

-

-:Description: Defines the color to use when emitting debug messages

-:Default: dark gray

-:Ini Section: colors

-:Ini Key: debug

-:Environment: :envvar:`ANSIBLE_COLOR_DEBUG`

-

-.. _COLOR_DEPRECATE:

-

-COLOR_DEPRECATE

-

-:Description: Defines the color to use when emitting deprecation messages

-:Default: purple

-:Ini Section: colors

-:Ini Key: deprecate

-:Environment: :envvar:`ANSIBLE_COLOR_DEPRECATE`

-

-.. _COLOR_DIFF_ADD:

-

-COLOR_DIFF_ADD

-

-:Description: Defines the color to use when showing added lines in diffs

-:Default: green

-:Ini Section: colors

-:Ini Key: diff_add

-:Environment: :envvar:`ANSIBLE_COLOR_DIFF_ADD`

-

-.. _COLOR_DIFF_LINES:

-

-COLOR_DIFF_LINES

-

-:Description: Defines the color to use when showing diffs

-:Default: cyan

-:Ini Section: colors

-:Ini Key: diff_lines

-:Environment: :envvar:`ANSIBLE_COLOR_DIFF_LINES`

-

-.. _COLOR_DIFF_REMOVE:

-

-COLOR_DIFF_REMOVE

-

-:Description: Defines the color to use when showing removed lines in diffs

-:Default: red

-:Ini Section: colors

-:Ini Key: diff_remove

-:Environment: :envvar:`ANSIBLE_COLOR_DIFF_REMOVE`

-

-.. _COLOR_ERROR:

-

-COLOR_ERROR

-

-:Description: Defines the color to use when emitting error messages

-:Default: red

-:Ini Section: colors

-:Ini Key: error

-:Environment: :envvar:`ANSIBLE_COLOR_ERROR`

-

-.. _COLOR_HIGHLIGHT:

-

-COLOR_HIGHLIGHT

-

-:Description: Color used for highlights

-:Default: white

-:Ini Section: colors

-:Ini Key: highlight

-:Environment: :envvar:`ANSIBLE_COLOR_HIGHLIGHT`

-

-.. _COLOR_OK:

-

-COLOR_OK

-

-:Description: Defines the color to use when showing 'OK' task status

-:Default: green

-:Ini Section: colors

-:Ini Key: ok

-:Environment: :envvar:`ANSIBLE_COLOR_OK`

-

-.. _COLOR_SKIP:

-

-COLOR_SKIP

-

-:Description: Defines the color to use when showing 'Skipped' task status

-:Default: cyan

-:Ini Section: colors

-:Ini Key: skip

-:Environment: :envvar:`ANSIBLE_COLOR_SKIP`

-

-.. _COLOR_UNREACHABLE:

-

-COLOR_UNREACHABLE

-

-:Description: Defines the color to use on 'Unreachable' status

-:Default: bright red

-:Ini Section: colors

-:Ini Key: unreachable

-:Environment: :envvar:`ANSIBLE_COLOR_UNREACHABLE`

-

-.. _COLOR_VERBOSE:

-

-COLOR_VERBOSE

-

-:Description: Defines the color to use when emitting verbose messages. i.e those that show with '-v's.

-:Default: blue

-:Ini Section: colors

-:Ini Key: verbose

-:Environment: :envvar:`ANSIBLE_COLOR_VERBOSE`

-

-.. _COLOR_WARN: