cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

[Docs][backport][2.10] Backportapalooza 12 (#71842)

Browse source 
* Fix typo in the documentation (#71701)

Fix typo in the documentation: casting instead of casing

(cherry picked from commit 1a06587f3b)

* Add how to run unit test link in testing_units_modules doc (#71523)

* Add how to run unit test link in testing_units_modules
* Fix sanity test

(cherry picked from commit 7a0e545700)

* Fix typo in delveloping_plugins_network (#71737)

(cherry picked from commit 4bf61f0714)

* Fix broken bullet list (#71728)

(cherry picked from commit 00ed5b1f2e)

* vmware: Add docs for filters (#71670)

Add a scenario guide for filters in VMware documentation

Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
(cherry picked from commit 760334303b)

* [docs] add porting guide for DNF GPG validation (#71640)

* [docs] add porting guide for DNF GPG validation

Change:
- This was a breaking change (security fix), but I neglected to add a
  porting guide entry for it previously.

Tickets:
- Refs #71537
- Refs #71539
- Refs #71540
- Refs #71541

Signed-off-by: Rick Elrod <rick@elrod.me>

* changes from sivel

Signed-off-by: Rick Elrod <rick@elrod.me>
(cherry picked from commit 7a38c470ba)

* Fixed invalid urls inside guide_packet.rst and collections_using.rst (#71705)

* Fixed invalid urls inside guide_packet.rst and collections_using.rst

* Reverted fix for collections_using.rst

(cherry picked from commit c36e939414)

* Update EXAMPLES in package_facts.py documentation (#71838)

this module is not limited to rpm , so remove rpm in tasks name

(cherry picked from commit 7f62b4733d)

* change duplicated label

(cherry picked from commit bcfead8e0f)

Co-authored-by: Guillaume Vincent <guillaume@oslab.fr>
Co-authored-by: Amin Vakil <info@aminvakil.com>
Co-authored-by: Shufeng <fenghhk@gmail.com>
Co-authored-by: Evaristo Rojas <evaristo.rojas@islas.org.mx>
Co-authored-by: Abhijeet Kasurde <akasurde@redhat.com>
Co-authored-by: Rick Elrod <rick@elrod.me>
Co-authored-by: Shounak <25407872+shounak1@users.noreply.github.com>
Co-authored-by: roumano <roumano@gmail.com>
This commit is contained in:
Sandra McCann 2020-09-21 16:42:39 -04:00 committed by GitHub
parent 47cabb1d32
commit b739bbe0a5
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
14 changed files with 264 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/docsite/rst/dev_guide/developing_program_flow_modules.rst
View file

@ -579,7 +579,7 @@ type
* bytes
* bits
The ``raw`` type, performs no type validation or type casing, and maintains the type of the passed value.
The ``raw`` type, performs no type validation or type casting, and maintains the type of the passed value.
elements
""""""""

26
docs/docsite/rst/dev_guide/testing.rst
View file

@ -174,6 +174,32 @@ Some ideas of what to test are:
* Test to see if any Python backtraces returned (that's a bug)
* Test on different operating systems, or against different library versions
Run sanity tests
````````````````
.. code:: shell
ansible-test sanity
More information: :ref:`testing_sanity`
Run unit tests
``````````````
.. code:: shell
ansible-test units
More information: :ref:`testing_units`
Run integration tests
`````````````````````
.. code:: shell
ansible-test integration -v ping
More information: :ref:`testing_integration`
Any potential issues should be added as comments on the pull request (and it's acceptable to comment if the feature works as well), remembering to include the output of ``ansible --version``

2
docs/docsite/rst/network/dev_guide/developing_plugins_network.rst
View file

@ -9,7 +9,7 @@ Network connection plugins
Each network connection plugin has a set of its own plugins which provide a specification of the
connection for a particular set of devices. The specific plugin used is selected at runtime based
on the value of the ``ansible_network_os`` variable assigned to the host. This variable should be
set to the same value as the name of the plugin to be loaed. Thus, ``ansible_network_os=nxos``
set to the same value as the name of the plugin to be loaded. Thus, ``ansible_network_os=nxos``
will try to load a plugin in a file named ``nxos.py``, so it is important to name the plugin in a
way that will be sensible to users.

2
docs/docsite/rst/porting_guides/porting_guide_2.8.rst
View file

@ -375,6 +375,8 @@ that may occur in execution.
* If you changed any tasks to specify less restrictive permissions while using 2.8.14, those changes will be unnecessary (but will do no harm) in 2.8.15.
* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it.
* ``dnf`` and ``yum`` - As of version 2.8.15, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task.
Modules removed
---------------

2
docs/docsite/rst/porting_guides/porting_guide_2.9.rst
View file

@ -78,6 +78,8 @@ Modules
* If you changed any tasks to specify less restrictive permissions while using 2.9.12, those changes will be unnecessary (but will do no harm) in 2.9.13.
* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it.
* ``dnf`` and ``yum`` - As of version 2.9.13, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task.
Renaming from ``_facts`` to ``_info``
--------------------------------------

2
docs/docsite/rst/porting_guides/porting_guide_base_2.10.rst
View file

@ -55,6 +55,8 @@ Modules
* If you changed any tasks to specify less restrictive permissions while using 2.10.0, those changes will be unnecessary (but will do no harm) in 2.10.1.
* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it.
* ``dnf`` and ``yum`` - As of version 2.10.1, the ``dnf`` module (and ``yum`` action when it uses ``dnf``) now correctly validates GPG signatures of packages (CVE-2020-14365). If you see an error such as ``Failed to validate GPG signature for [package name]``, please ensure that you have imported the correct GPG key for the DNF repository and/or package you are using. One way to do this is with the ``rpm_key`` module. Although we discourage it, in some cases it may be necessary to disable the GPG check. This can be done by explicitly adding ``disable_gpg_check: yes`` in your ``dnf`` or ``yum`` task.
Noteworthy module changes
-------------------------

2
docs/docsite/rst/scenario_guides/guide_packet.rst
View file

@ -123,7 +123,7 @@ You can also identify specific Packet devices with the 'device_ids' parameter. T
More Complex Playbooks
======================
In this example, we'll create a CoreOS cluster with `user data <https://support.packet.com/kb/articles/user-data>`_.
In this example, we'll create a CoreOS cluster with `user data <https://packet.com/developers/docs/servers/key-features/user-data/>`_.
The CoreOS cluster will use `etcd <https://etcd.io/>`_ for discovery of other servers in the cluster. Before provisioning your servers, you'll need to generate a discovery token for your cluster:

1
docs/docsite/rst/scenario_guides/guide_vmware.rst
View file

@ -19,6 +19,7 @@ To get started, please select one of the following topics.
vmware_scenarios/vmware_inventory
vmware_scenarios/vmware_inventory_vm_attributes
vmware_scenarios/vmware_inventory_hostnames
vmware_scenarios/vmware_inventory_filters
vmware_scenarios/vmware_scenarios
vmware_scenarios/vmware_troubleshooting
vmware_scenarios/vmware_external_doc_links

216
docs/docsite/rst/scenario_guides/vmware_scenarios/vmware_inventory_filters.rst Normal file
View file

@ -0,0 +1,216 @@
.. _vmware_ansible_inventory_using_filters:
***********************************************
Using VMware dynamic inventory plugin - Filters
***********************************************
.. contents::
:local:
VMware dynamic inventory plugin - filtering VMware guests
=========================================================
VMware inventory plugin allows you to filter VMware guests using the ``filters`` configuration parameter.
This section shows how you configure ``filters`` for 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.
Alternately, 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.
Let us assume we want to list all RHEL7 VMs with the power state as "poweredOn". A valid inventory file with filters for the given VMware guest looks as follows:
.. 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
filters:
- config.guestId == "rhel7_64Guest"
- summary.runtime.powerState == "poweredOn"
Here, we have configured two filters -
* ``config.guestId`` is equal to ``rhel7_64Guest``
* ``summary.runtime.powerState`` is equal to ``poweredOn``
This retrieves all the VMs which satisfy these two conditions and populates them in the inventory.
Notice that the conditions are combined using an ``and`` operation.
Using ``or`` conditions in filters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Let us assume you want filter RHEL7 and Ubuntu VMs. You can use multiple filters using ``or`` condition in your inventory file.
A valid filter in the VMware inventory file for this example is:
.. 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
filters:
- config.guestId == "rhel7_64Guest" or config.guestId == "ubuntu64Guest"
You can check all allowed properties for filters for the given virtual machine at :ref:`vmware_inventory_vm_attributes`.
If you are using the ``properties`` parameter with custom VM properties, make sure that you include all the properties used by filters as well in your VM property list.
For example, if we want all RHEL7 and Ubuntu VMs that are poweredOn, you can use inventory file:
.. 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'
properties:
- 'config.name'
- 'config.guestId'
- 'guest.ipAddress'
- 'summary.runtime.powerState'
filters:
- config.guestId == "rhel7_64Guest" or config.guestId == "ubuntu64Guest"
- summary.runtime.powerState == "poweredOn"
Here, we are using minimum VM properties, that is ``config.name``, ``config.guestId``, ``summary.runtime.powerState``, and ``guest.ipAddress``.
* ``config.name`` is used by the ``hostnames`` parameter.
* ``config.guestId`` and ``summary.runtime.powerState`` are used by the ``filters`` parameter.
* ``guest.guestId`` is used by ``ansible_host`` internally by the inventory plugin.
Using regular expression in filters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Let us assume you want filter VMs with specific IP range. You can use regular expression in ``filters`` in your inventory file.
For example, if we want all RHEL7 and Ubuntu VMs that are poweredOn, you can use inventory file:
.. 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'
properties:
- 'config.name'
- 'config.guestId'
- 'guest.ipAddress'
- 'summary.runtime.powerState'
filters:
- guest.ipAddress is defined and guest.ipAddress is match('192.168.*')
Here, we are using ``guest.ipAddress`` VM property. This property is optional and depended upon VMware tools installed on VMs.
We are using ``match`` to validate the regular expression for the given IP range.
Executing ``ansible-inventory --list -i <filename>.vmware.yml`` creates a list of the virtual machines that are ready to be configured using Ansible.
What to expect
--------------
You will notice that the inventory hosts are filtered depending on your ``filters`` section.
.. code-block:: yaml
{
"_meta": {
"hostvars": {
"template_001": {
"config.name": "template_001",
"config.guestId": "ubuntu64Guest",
...
"guest.toolsStatus": "toolsNotInstalled",
"summary.runtime.powerState": "poweredOn",
},
"vm_8046": {
"config.name": "vm_8046",
"config.guestId": "rhel7_64Guest",
...
"guest.toolsStatus": "toolsNotInstalled",
"summary.runtime.powerState": "poweredOn",
},
...
}
Troubleshooting filters
-----------------------
If the custom property specified in ``filters`` 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 of the 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

11
docs/docsite/rst/scenario_guides/vmware_scenarios/vmware_inventory_hostnames.rst
View file

@ -4,9 +4,10 @@
Using VMware dynamic inventory plugin - Hostnames
*************************************************
.. contents:: Topics
.. contents::
:local:
VMware dynamic inventory plugin - Customizing hostnames
VMware dynamic inventory plugin - customizing hostnames
=======================================================
@ -36,14 +37,14 @@ To install the latest ``community.vmware`` collection:
To use this VMware dynamic inventory plugin:
1. Enable it first by specifying the following in the ``ansible.cfg`` file:
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.
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.
@ -67,7 +68,7 @@ the ``config.name`` property from the virtual machine and populate it in the inv
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.
Executing ``ansible-inventory --list -i <filename>.vmware.yml`` creates a list of the virtual machines that are ready to be configured using Ansible.
What to expect
--------------

3
docs/docsite/rst/user_guide/intro_getting_started.rst
View file

@ -50,11 +50,8 @@ Beyond the basics
You can override the default remote user name in several ways, including:
* passing the ``-u`` parameter at the command line
* setting user information in your inventory file
* setting user information in your configuration file
* setting environment variables
See :ref:`general_precedence_rules` for details on the (sometimes unintuitive) precedence of each method of passing user information. You can read more about connections in :ref:`connections`.

4
docs/docsite/rst/user_guide/intro_inventory.rst
View file

@ -169,7 +169,7 @@ In YAML:
webservers:
hosts:
www[01:50].example.com:
You can specify a stride (increments between sequence numbers) when defining a numeric range of hosts:
In INI:
@ -200,7 +200,7 @@ For numeric patterns, leading zeros can be included or removed, as desired. Rang
Adding variables to inventory
=============================
You can store variable values that relate to a specific host or group in inventory. To start with, you may add variables directly to the hosts and groups in your main inventory file. As you add more and more managed nodes to your Ansible inventory, however, you will likely want to store variables in separate host and group variable files.
You can store variable values that relate to a specific host or group in inventory. To start with, you may add variables directly to the hosts and groups in your main inventory file. As you add more and more managed nodes to your Ansible inventory, however, you will likely want to store variables in separate host and group variable files. See :ref:`define_variables_in_inventory` for details.
.. _host_variables:

4
docs/docsite/rst/user_guide/playbooks_variables.rst
View file

@ -193,7 +193,7 @@ Where to set variables
You can define variables in a variety of places, such as in inventory, in playbooks, in reusable files, in roles, and at the command line. Ansible loads every possible variable it finds, then chooses the variable to apply based on :ref:`variable precedence rules <ansible_variable_precedence>`.
.. _variables_in_inventory:
.. _define_variables_in_inventory:
Defining variables in inventory
-------------------------------
@ -363,7 +363,7 @@ Tips on where to set variables
You should choose where to define a variable based on the kind of control you might want over values.
Set variables in inventory that deal with geography or behavior. Since groups are frequently the entity that maps roles onto hosts, you can often set variables on the group instead of defining them on a role. Remember: Child groups override parent groups, and host variables override group variables. See :ref:`variables_in_inventory` for details on setting host and group variables.
Set variables in inventory that deal with geography or behavior. Since groups are frequently the entity that maps roles onto hosts, you can often set variables on the group instead of defining them on a role. Remember: Child groups override parent groups, and host variables override group variables. See :ref:`define_variables_in_inventory` for details on setting host and group variables.
Set common defaults in a ``group_vars/all`` file. See :ref:`splitting_out_vars` for details on how to organize host and group variables in your inventory. Group variables are generally placed alongside your inventory file, but they can also be returned by dynamic inventory (see :ref:`intro_dynamic_inventory`) or defined in :ref:`ansible_tower` from the UI or API::

4
lib/ansible/modules/package_facts.py
View file

@ -42,11 +42,11 @@ author:
'''
EXAMPLES = '''
- name: Gather the rpm package facts
- name: Gather the package facts
package_facts:
manager: auto
- name: Print the rpm package facts
- name: Print the package facts
debug:
var: ansible_facts.packages