You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 22, 2023. It is now read-only.
In most production environments, there will be some config drift that aren't easily fixable, or in some network OSes, they sometimes change what would be an ordered list into an unordered list. While ordered lists are critical for things like ACLs, they can be seen as minor features for things like DNS or NTP servers. As such, an option to allow for loose ordering can be useful so we don't get false positives like this:
ok: [localhost] => {
"msg": {
"changed": false,
"failed": true,
"msg": "Validation failed for the following nodes: ['veos1'].",
"result": {
"veos1": {
"NTP.NTP_Servers": {
"actual": [
"10.0.0.1",
"time-a-g.nist.gov",
"time-e-b.nist.gov"
],
"expected": [
"time-a-g.nist.gov",
"10.0.0.1",
"time-e-b.nist.gov"
]
}
}
},
"summary": "Validation failed for the following nodes: ['veos1']."
}
}
I see something like this being definied in the category of a validation yml file like:
In most production environments, there will be some config drift that aren't easily fixable, or in some network OSes, they sometimes change what would be an ordered list into an unordered list. While ordered lists are critical for things like ACLs, they can be seen as minor features for things like DNS or NTP servers. As such, an option to allow for loose ordering can be useful so we don't get false positives like this:
I see something like this being definied in the category of a validation yml file like:
The text was updated successfully, but these errors were encountered: