Release 2.0.0

Summary

This release is a major rewrite of the modules in this Juniper.junos role. This release offers several new features and bug fixes over previous releases, yet it still maintains backwards compatibility with playbooks written to previous releases of the Juniper.junos role. The following sections highlight some of the changes in this release.

Important Installation Note

The ansible-galaxy install command does not support a smooth upgrade from previous releases to this release. Therefore, you must first remove any previous versions of the Juniper.junos role by executing:

sudo ansible-galaxy remove Juniper.junos

Once previous versions have been removed, the current version of the Juniper.junos role may be installed with:

sudo ansible-galaxy install Juniper.junos

New Features

Modules renamed and re-organized.

Ansible added core modules for managing Junos devices in Ansible release 2.1. Since that time, there's been a lot of confusion between the Ansible-provided and supported modules in Ansible core and the Juniper-provided and supported modules in this Juniper.junos role. Part of this confusion was due to the similar names (and functionality) between the two sets of modules. Module renaming helps distinguish between the two sets of modules by:

1. The new names for modules in this Juniper.junos role name all start with the prefix juniper_junos_ to indicate that the module is part of the Juniper.junos role, and that the module is written and supported by Juniper.
2. Removes the direct naming conflict which existed with the junos_rpc module.
3. Removes verbs such as get and install from the module names in order to better follow Ansible best practices.
4. Removes the cli misnomer from the junos_cli module by renaming it to juniper_junos_command. The new name better indicates the module uses the NETCONF <command> RPC to execute the equivalent of a CLI command.
5. Consolidates multiple modules which deal with the same component (such as the configuration or system) into a single module per component.

NOTE

If a playbook worked with a prior version of the Juniper.junos role, it should continue to work on the current version without requiring modifications to the playbook. However, these older module and argument names are no longer present in the current documentation. You may reference previous module and argument names by referring directly to the 1.4.3 version of the Juniper.junos role documentation.

The following table provides a mapping between new and old module names:

New Module Name	Old Module Name	New Arguments/Values Required to Mimic Old Module Behavior
juniper_junos_command	junos_cli
juniper_junos_config	junos_commit	commit=True, diff=False, check=False
juniper_junos_config	junos_get_config	retrieve="candidate"
juniper_junos_config	junos_install_config	load="merge|update|replace|override"
juniper_junos_config	junos_rollback	rollback=<value>
juniper_junos_facts	junos_get_facts
juniper_junos_jsnapy	junos_jsnapy
juniper_junos_ping	junos_ping
juniper_junos_pmtud	junos_pmtud
juniper_junos_rpc	junos_rpc
juniper_junos_software	junos_install_os
juniper_junos_srx_cluster	junos_srx_cluster
juniper_junos_system	junos_shutdown	action="shutdown" or action="off" or action="reboot"
juniper_junos_system	junos_zeroize	state="zeroize"
juniper_junos_table	junos_get_table

Enhanced Connection-related Module Arguments (common for all modules)

• The host argument now defaults to {{ inventory_hostname }}. This means the host argument is no longer required unless connecting to a Junos device through a console server.
• Aliases have been added for several connection arguments to support compatibility with the argument names used by the core Ansible modules for Junos. Specifically:
  • The host argument may now be alternatively specified using the hostname or ip argument aliases.
  • The user argument may now be alternatively specified using the username argument alias.
  • The passwd argument may now be alternatively specified using the password argument alias.
  • The ssh_private_key_file argument may now be alternatively specified using the ssh_keyfile argument alias.
• The algorithm for selecting the default value of the user, passwd, and ssh_private_key_file arguments has been enhanced. In many cases, this means these parameters no longer need to be specified in each task. See the module documentation for details on the default values for these arguments.
• The algorithm for selecting the default value of the user, passwd, and ssh_private_key_file arguments is compatible with Ansible Tower.
• All connection-related arguments may now be, optionally, specified as sub-arguments of a provider argument. This allows connection-related parameters to be specified in the same format used by the core Ansible modules for Junos.
• All modules support a common set of connection-related arguments using a common library of code. This ensures the connection-related arguments behave consistently across all modules in the Juniper.junos role.

Enhanced Logging (common for all modules)

• All modules in the Juniper.junos role support a common set of logging arguments.
• When the logdir or logfile option is specified, the following messages are logged:
  1. By default, messages at level WARNING or higher are logged.
  2. If the -v or --verbose command-line options to the ansible-playbook command are specified, messages at level INFO or higher are logged.
  3. If the -vv (or more verbose) command-line option to the ansible-playbook command is specified, or the ANSIBLE_DEBUG environment variable is set, then messages at level DEBUG or higher are logged.

juniper_junos_command Module

• The output of the command is available in the module's return value. It does not have to be saved to a file.
• For xml and json format types, the output of the command is available as both an unparsed string and a parsed data structure.
• Supports a list of commands to execute, rather than just a single command.

juniper_junos_config Module

• Any combination of loading or rolling back, checking, diffing, retrieving, and committing the configuration of a Junos device can now be performed in a single task.
• Configurations may be loaded from local filesystem of a Junos device or a remote URL using the url argument.
• Configurations may be loaded directly from a rendered Jinja2 template using the template and vars arguments.
• Configurations may be loaded directly from a list of strings using the lines argument.
• Configurations may be loaded using exclusive mode (the default) or private mode.
• The candidate or committed configurations can be retrieved from the device.
• The retrieved configuration is available in the module's return value.
• Ability to ignore warnings.

juniper_junos_facts Module

• Acts as an official fact plugin so that facts are registered under the junos hostvar.
• Supports optionally retrieving the committed configuration as a fact.

juniper_junos_rpc Module

• The output of the RPC is available in the module's return value. It does not have to be saved to a file.
• For xml and json format types, the output of the RPC is available as both an unparsed string and a parsed data structure.
• Supports a list of RPCs to execute, rather than just a single RPC.

juniper_junos_software Module

• Support ISSU / NSSU.
• Support timeouts for the various stages of the software install process.
• Support the ability to disable cleanfs.

juniper_junos_system Module

• Support a rollback rescue equivalent.
• When performing a rollback, return config diffs in the response data structure.

Maintainability

Verified functionality with Ansible releases 2.1 to 2.4

Console connectivity to Junos devices is now provided by PyEZ rather than the Netconify library

• This ensures that all modules support connecting to the Junos device via console.
• The Netconify library is no longer a required package.

Better error handling of missing required libraries or unmet minimum versions.

Bugs Fixed

junos_shutdown - XMLSyntaxError' object has no attribute 'rsp #243

get_table - rpc timeout #242

'junos_install_os' fails without 'logfile' parameter #246

junos_install_os with NSSU get exceptions #244

junos_install_os fails to execute on a SRX320 #227

###"Uncaught exception - please report: Type 'str' cannot be serialized." #137