Configuration Manager

BREAKING CHANGE for 2020.2 → 2021.2

The following are breaking changes for the 2020.2 release.

Invalid Variables Error Update

When you create a Jinja2 template in Golden Configuration requiring variables that are not provided during runtime, the runCompliance task throws an error.

Previously, if invalid variables were passed, the system would process compliance with the last successfully saved Jinja2 configuration. With this update, however, if you create a Jinja2 template that requires variables that are not provided during runtime, an error occurs.

The following example illustrates an invalid hostname variable for the runCompliance task.

Sample Variable

{
    "vars": {
        "hostname": "Itential"
    }
}

Sample Template

hostname {{hostname}} 
interface Loopback1
ip address 125.52.71.226

The variable required in the template example is hostname, but a root level variable called hostname does not exist. Instead, the root level variable is called vars.hostname. So when Jinja2 attempts to access the hostname variable, an error occurs because hostname cannot be found by the runCompliance task.

What should I do?

Because errors are now thrown on exception for invalid variables, you must create an error transition coming out of the runCompliance, runComplianceForTree, runComplianceForNode, and runComplianceForDevice tasks in your workflow.

BREAKING CHANGE for 2021.2

The following are breaking changes for the 2021.2 release.

Golden Configuration Regular Expressions Engine Update

The RegEx engine in Golden Configuration has received an update to handle full-line RegEx matching.

Regular expressions in Configuration Manager previously were confined within the bounds of a word. If you wanted to define a regex, it would apply to only one word in the entire config line. You were not able to check the validity of an entire config line with one regex.

This RegEx engine update enables the regular expression to work as you usually expect, with a wider scope. In other words, you can validate an entire configuration line with one regular expression declaration.

Previously, if you wanted to check whether the following config exists:

no cable admission-control preempt priority-voice
no cable qos permission create
no cable qos permission update
no cable qos permission modems

In the old regex engine you would have to define it like this:

no cable {/.*/} {/.*/} {/.*/}

⚠ There is a caveat with this approach, if a line has more or less than 5 words, then the defined regex would not work.

For example, this config will not be captured with the above regex:

no cable acfe max-bonus-bandwidth

This is because it has a length of 4 words. In order for the regular expression matching to capture the line, you would have to define it as the following line:

no cable {/.*/} {/.*/}

However, now that full line regular expressions are supported, you can simply do:

no cable {/.*/}

What should I do?

There are currently two cases of regular expressions that require updates for compatibility with the new engine.

For the first case regarding Anchors, you may run the validation script in the Configuration Manager utils directory called validateRegexs.js. This will check all of your trees and nodes, and notify you of regular expressions that have anchors that need to be revised.

The second case of regular expressions that require updates are partial regular expressions. The sections below will explain in more detail how you can tackle existing regular expressions in your Golden Configurations to achieve maximum compatibility with the new regular expression engine.

Remove Anchors from All Regular Expressions

Anchors are now automatically applied around the config lines by the algorithm to define their bounds. Therefore, if you have anchors around a word or regex, they must be removed.

For example:

ip dhcp excluded-address {/^.*$/} {/^.*$/}

Anchors (^, $) must be removed for the new regular expression engine. Doing so should yield:

ip dhcp excluded-address {/.*/}

Define Partial Regexs

If you only want to validate part of the word through a regex (assuming no anchors), then you must redefine it properly. For example, on a config:

interface Loopback1

If you defined the following regular expression in the old engine to do a partial match:

interface {/Loopback/}

Then you would see that it matched Loopback1 because no anchors implied that partial word matches be returned as true.

However, in the new engine you must be definitive with your behavior. If you want to match a partial word, you must define it with the proper regex:

interface {/Loopback.*/}