Developer Docs

Running tests

1. Set up a virtual env

mkvirtualenv inmanta-test -p python3
pip install -r requirements.dev.txt
pip install -r requirements.txt

mkdir /tmp/env
export INMANTA_TEST_ENV=/tmp/env
export INMANTA_MODULE_REPO=git@github.com:inmanta/
# Optional value to set in environments with large config files. 60 seconds is used if not specified.
export N5K_NETCONF_TIMEOUT="60"

2. Provide a device under test

The integration tests (test_handler, test_session, test_n5k_netconf) talk to a Nexus device over NETCONF, selected via these env vars:

Var

Meaning

N5K_HOST / N5K_PORT

NETCONF host and port (22)

N5K_USER / N5K_PASS

credentials

N5K_OSV

set to true for an NX-OSv (virtual) device; unset for physical

N5K_INTERFACES

the Ethernet interface the tests use (e.g. 2/2)

N5K_BASE_CONFIG

base config the cleanup fixture restores over NETCONF (see below)

Containerlab NX-OSv (recommended, and what CI uses). A disposable NX-OSv stands in for the lab switch, so no shared lab device is needed. One-shot:

make ci-test    # containerlab deploy -> wait_for_netconf -> pytest -> destroy

This boots containerlab/n5k.clab.yml (the vr-nxos image run under the cisco_n9kv kind) and runs the suite against it. The N5K_* vars come from .ci-integration-tests.yml (the Jenkins pipeline injects them); export them yourself for a local run. See containerlab/README.md for the kind rationale, the pinned mgmt IP, and why the cleanup fixture pushes N5K_BASE_CONFIG over NETCONF instead of copy bootflash:///clean-fabricpath.cfg (virtual devices have no such bootflash file).

An existing device. Point the N5K_* vars at it and run:

pytest tests

Design

This handler uses netconf to send cli commands to the switch. netconf is also used to fetch the full configuration from the device.

The module consists of multiple entities:

  • A Resource for which one or more can be generated per device. This entity contains a desired state configuration commands that come from ManagedObjects in the configuration model.

  • ManagedObjects which are the entities that represent the desired state. Each managed object generates configuration commands. This module should be able to “partially” manage a switch. This means that all attributes that generate configuration lines should be nullable. null then means, do not manage the attribute and ignore it. As a consequence each managed object has a list of attributes that should be removed (e.g. no description). For flags, which are modelled as booleans this is not required (e.g. shutdown=false becomes no shutdown)

The handler uses a schema definition to generate an NX-OS edit script that can transform the current state into the desired state. This schema defines the tree structure that the IOS-like configuration of NX-OS is. It has a similar function what a yang schema does for xml based configuration.

Schema documentation

The schema file contains a list of components that match with lines in the configuration. Each component can have a list of children. These lines and the parent/child relation is translated into a set of internal Component model objects.

There are two schemas for Nexus 5500/5600:

  • nx-os

  • nx-osv

nx-os is a schema used by a real device whereas nx-osv is used by a virtual device

An object can have the following attributes:

  • name: The name of the component as it is seen in the config of the Nexus

  • type: This determines the type of configuration line. Currently the following types have been defined:

    • value: A line in which everything after name is considered as the value of the parameter (strippped of leading and trailing whitespaces).

    • flag: A flag parameter, can have True/False value. For example shutdown/no shutdown.

    • switch: A list of values to choose from a given set of values

    • container: An object that holds other objects with a common name

    • attribute_range_list: List of range objects which can have attributes. Attributes are presented in the config as values printed right after the range before the new line character.

    • field_range_list: List of range objects which can have fields. Fields are presented in the config as values / components which are printed with an indentation, each in a new line.

    • scripted_range_list: List of range objects without attributes nor fields. The list supports adding and removing items from it’s range with script syntax, i. e. add and remove keywords.

Example:

- name: interface
  type: container
  creatable: false
  children:
    - name: switchport
      type: flag
      default: true
    - name: switchport mode
      type: switch

Each schema component can have certain fields defined, which are:

  • name

  • type

  • creatable (no all components)

  • default (only children of container or fields of field_range_list)

There are also spefic fields for each component:

  • attributes

  • fields

  • value

Config object representation:

  • Config objects are represented according to the provided schema as object instances such as Container, ScriptedRangeList etc. The class hierarchy of the module is:

Class Diagram image

Notes: