This commit adds a new module, ops_command, that handles executing commands
on OpenSwitch over the CLI. Since this module is designed to work with the
OpenSwitch CLI, it only supports the CLI transport option
This commit adds a new module, ops_config, that allows playbook designers
to create tasks for configuring OpenSwitch over the CLI. The module
is designed to work directly with configuration mode in OpenSwitch and
therefore only supports the CLI transport option
This commit address a bug in the ios_config module when using the
match: strict argument. When the argument is used, the module will
compare the configuration block same as match: exact which is not the
intended behavior. This commit updates the behavior to propertly handle
the strict argument.
now uses atomic move to avoid data corruption
correclty cleans up temp files in every case
returns backup_file info if needed
validate validate before temp file gets created
backup AFTER validate
Without this change, a download failure may bail out with the message:
"Failure downloading http://foo/bar, 'NoneType' object has no attribute 'read'"
whereas with this fix, you'd get a proper error like:
"Failure downloading http://foo/bar, Request failed: <urlopen error [Errno 113] No route to host>"
or one of the many other possible download errors that can occur.
The returned list of diffs aims to simulate how a file system diff would
look before and after writing the sources list files.
n.b. Ternary conditional is due to failing integration test for
python 2.4
This commit refactors the arugments used in ops_template to be strictly
typed and handle by declarative / rest and cli based configurations. It
also removes old arguments not supported and cleans up the documentation
strings
This mirrors a nearly identical change made to apt_repository.py.
Also removes the use of apt-get --force-yes as it can be dangerous
and should not be necessary (apt_repository.py does not use it).
Repeating the explanation from the apt_respository change below:
Since use_unsafe_shell is suspicious from a security point
of view (or it wouldn't be unsafe), the less we have, the less
code we have to thoroughly inspect for a security audit.
In this case, the '&&' can be replaced by doing 2 calls to run_command.
Running async_status in an "until: result.finished" loop will mask a module failure (eg, traceback) with a
template failure, because the fail dict doesn't include "finished" (eg, you'll see "ERROR! The conditional check 'bogus_out.finished' failed. The error was: ERROR! error while evaluating conditional: bogus_out.finished ({% if bogus_out.finished %} True {% else %} False {% endif %}"). Because the failure dict still includes "failed: true",
this change has no effect on stoppage/failure reporting, it just prevents the common usage pattern from masking the underlying error message.
Since our validation does conversion as well as validation, I'm not sure
this is entirely correct. May need to take a look at our conversion
code and re-examine to be sure we're doing it right.
I like to use ~/somepath instead of absolute paths because
that's more shareable. Without expansion, the path wasn't
considered a file, and the resulting cloud-config user_data
contained a string for the file path instead of the file context.
So, expand it.
restart_containers(containers.running) may try to restart containers
that are deleted when looping through get_differing_containers()
fix this by refreshing list after first loop
The ulimit will be specified as a list and separated by colons. The
hard limit is optional, in which case it is equal to the soft limit.
The ulimits are compared to the ulimits of the container and added
or adjusted accordingly on by a reload.
The module ensures that ulimits are available in the capabilities
iff ulimits is passes as a parameter.
This adds a new module, iosxr_config, that can be used for configuring
Cisco IOS XR devices. It is provides a set of arguments for sending
configuration commands to the device over cli
This adds a new module, iosxr_template, that can be used to template
configurations for IOS XR devices. Templates are then loaded into the
target device over cli
A change is coming to Ansible where module params will default to str.
Many of our modules were taking advantage of this by not being explicit
about the type, so they will break when that change merges. This hopefully
catches those cases.
- clarify docs on body_json behaviour
- only tranform into json if body input is not a string
users keep passing json string and expecint it to not be jsonified again
- fixed issue with removes not handling path expansion correctly
- switched all path variables to 'type path' to handle expansions
This commit allows the connection information for
the vsphere_guest module to be provided as environment
variables, which makes it possible to use Cloud
Credentials from Ansible Tower in playbooks that utilize
vsphere_guest.
| ENV VAR | vsphere_guest param |
| --------------- | ---------------------- |
| VMWARE_HOST | vcenter_hostname |
| VMWARE_USER | username |
| VMWARE_PASSWORD | password |
This adds a new module, junos_config, useed to configure Juniper JUNOS based
devices. The config module can be used to set an ordered set of set and
delete statements over a cli transport
This adds a new module, junos_template, that can read in a template
config and push the changes to the device. It can also backup the
current config. This module is implemented over cli
This adds a new module, junos_command that can be used for sending commands
to Juniper JUNOS based devices. The junos_command module is implemented
over a cli transport
Fix the OpenStack os_server module for when region_name is specified.
This should not be passed through to the shade create_server() call
as it's only used with the auth parameters.
Fixes bug: https://github.com/ansible/ansible-modules-core/issues/2797
This change update the return values from eos_config to be consistent with
all network config modules. This will now return updates and responses
from the module
This change updates the returns values from eos_command to be consistent
with network modules. It now returns stdout, stdout_lines and failed_conditionals
This updates the nxos_template doc string to unify the return values
across all network modules. This change now returns stdout, stdout_lines
and failed_conditionals
This modifies the return values to make them consistent across all
network command modules. The module now returns stdout, stdout_lines
and failed_conditionals
- defaulted to commands not executing in checkmode
- added force run for info gathering (for setting changed)
- added debug for what would have been run in check mode
- added check mode for spots that made changes using system calls instead of command
- removed now redundant checkmode checks
better failure now, if i missed anything, it will misreport changed value
instead of old default of actually making the change in checkmode
The old method left settings in the environment. The new method takes
care of clearing them after use. In this module, the old method was
also setting the environment too late to affect all the command line
tools which lead to a bug.
Fixes https://github.com/ansible/ansible/issues/14264
This addresses a bug in the eos_config module that would prevent it
from running properly. The module should now properly process the config
and the candidate
The eos_config module has a bug where its trying to pass an argument
that doesn't exist. This fixes that problem, removing the offending
keywork argment
The eos_template module works by allowing configurations to be pushed
to Arista EOS devices that can be templated by the Ansible Jinja2
template engine
The nxos_template module worksw by allowing configurations to be pushed
to Cisco NXOS devices over CLI or NXAPI and templated using the Ansible
Jinja2 template engine
