Network:Core roadmap 2.5

Status: DRAFT

This is an uncommitted roadmap for 2.5

Feedback welcome in #ansible-network

Follow the our progress

GitHub Project

Note: To see which cards in our project pertain to a specific roadmap item, use the filter cards feature and filter using the keyword associated with each roadmap item e.g. [NET_CONN].

Convert existing non-DI NXOS modules into Declarative Intent [DI_NXOS]

Most of the existing NXOS modules non-declarative intent which can be converted to Declarative intent. Declarative intent modules are designed to provide playbook designers a set of network modules that perform declarative configuration tasks on network devices. This includes the ability to declaratively describe a configuration set. With 2.5.0 release the existing NXOS modules will be converted to DI module.

Add missing declarative intent modules for supported platforms [DI_MISSING]

Add the missing declarative intent modules which were supposed to be added in 2.4. Declarative intent modules are designed to provide playbook designers a set of network modules that perform declarative configuration tasks on network devices. This includes the ability to declaratively describe a configuration set. With 2.5.0 release we aim to complete the list of the declarative intent modules.

Network connection plugin work as part of core effort [NET_CONN]

A lot of persistent weirdness in Ansible networking comes down to the use of connection: local to talk to network devices. The 2.5 release will introduce two new connection types, network_cli and netconf, for cli and netconf connections respectively. These connection types let us further harness base Ansible features, such as become: yes for command elevation. Additionally, connection types for eapi and nxapi will be added in 2.5 if possible.

Refactor common platform libraries to using CliConf plugin [CLI_CONF]

Refactor modules and utilities of network platforms that use cli transport to leverage CliConf plugins added as part of 2.4. The CliConf plugins add API abstraction for low level CLI operations and the communication between module and plugins will be over JSONRPC 2.0. Platforms impacted: ios, iosxr, nxos, junos, eos, vyos

Refactor common platform libraries to using NetConf plugin [NETCONF]

Add connection plugins and module utilities to support NetConf protocol based configuration management. JUNOS and IOS-XR support for 2.5 release. The plugins shall support getting device capabilities and will be build on top of ncclient. The communication between ansible-connection process and the connection plugins will be over JSONRPC 2.0

Parse xml filter for network use case to return a json object [XML_FILTER]

Add parse_xml filter to convert the XML output of a network device command into structured JSON. The filter will load the spec file and pass the command output through formatted as JSON. The spec file should be valid formatted YAML, it defines how to parse the XML output and return JSON data.

Implement more flexible action handler plugin [ACTION_HANDLER]

Continuous Integration and Testing [CI] [TESTING]

Documentation [DOCS]

Create documentation for new users (getting started) and advanced users (such as how to authentication) to reduce confusion on how to best use Ansible to manage network devices. This will include creating a new landing page (which all network modules will link to); documenting various use-cases. Also where relevant existing Core (not network-specific) documentation will be reviewed and improved, this will be an ongoing process over the next few Ansible releases.

Refactor network common libraries into module_utils/network packaging [COMMON_LIB]

The rapid pace of module development for network modules has amassed a significant amount of technical debt related to the network shared code found in ansible/module_utils. This proposal is designed to provide details on creating a stable network package in ansible/module_utils/network and move the current shared network libraries into the new package. The ansible.module_utils.network package will only contain shared code that is common for all network modules to implement and will be maintained in a stable way moving forward.