ansible.netcommon.persistent connection – Use a persistent unix socket for connection
Note
This connection plugin is part of the ansible.netcommon collection (version 7.2.0).
You might already have this collection installed if you are using the ansible
package.
It is not included in ansible-core
.
To check whether it is installed, run ansible-galaxy collection list
.
To install it, use: ansible-galaxy collection install ansible.netcommon
.
To use it in a playbook, specify: ansible.netcommon.persistent
.
New in ansible.netcommon 1.0.0
Synopsis
This is a helper plugin to allow making other connections persistent.
Parameters
Parameter |
Comments |
---|---|
Reduce CPU usage and network module execution time by enabling direct execution. Instead of the module being packaged and executed by the shell, it will be directly executed by the Ansible control node using the same python interpreter as the Ansible process. Note- Incompatible with Choices:
Configuration:
|
|
Configures, in seconds, the amount of time to wait for a command to return from the remote device. If this timer is exceeded before the command returns, the connection plugin will raise an exception and close. Default: Configuration:
|
|
Configures, in seconds, the amount of time to wait when trying to initially establish a persistent connection. If this value expires before the connection to the remote device is completed, the connection will fail. Default: Configuration:
|
|
This flag will enable logging the command executed and response received from target device in the ansible log file. For this option to work ‘log_path’ ansible configuration option is required to be set to a file path with write access. Be sure to fully understand the security implications of enabling this option as it could create a security vulnerability by logging sensitive information in log file. Choices:
Configuration:
|
Note
Configuration entries listed above for each entry type (Ansible variable, environment variable, and so on) have a low to high priority order. For example, a variable that is lower in the list will override a variable that is higher up. The entry types are also ordered by precedence from low to high priority order. For example, an ansible.cfg entry (further up in the list) is overwritten by an Ansible variable (further down in the list).