Add hier config nested compliance rule feature - #979
Conversation
| @@ -0,0 +1,298 @@ | |||
| # Hierarchical Configuration Compliance | |||
There was a problem hiding this comment.
We should come up with a word that will resonate with the network engineer vs the technical implementation, such as partial match or filter configs.
There was a problem hiding this comment.
I've renamed it to Filtered Configuration Compliance. If that doesn't fit, let me know and I'll change it.
There was a problem hiding this comment.
If filtered doesn’t work for you, then how about “Advanced configuration compliance”
There was a problem hiding this comment.
My vote is Limited Configuration Compliance
|
|
||
| Filtered configuration compliance requires: | ||
|
|
||
| 1. **CLI Configuration Type**: Only `CLI` configuration types are supported for hierarchical compliance |
There was a problem hiding this comment.
Can we link to appropriate docs/repo here?
There was a problem hiding this comment.
I added a link to the cli compliance feature within these docs (app_feature_compliancecli.md). Is that sufficient?
| ## Fallback Behavior for Empty Intended Configuration | ||
|
|
||
| In some cases, the intended configuration may not contain any elements that match the compliance rules, resulting in an empty intended configuration text. To handle this scenario, the system includes a fallback mechanism: | ||
|
|
||
| **Interface Fallback**: When the intended configuration text is empty, the system automatically looks for top-level interface configurations in the running configuration and uses them as the intended configuration baseline. | ||
|
|
||
| This fallback behavior: | ||
|
|
||
| 1. **Triggers** when `intended_text` is empty after tag-based filtering | ||
| 3. **Filters** for lines that start with "interface" | ||
| 4. **Uses** these interface declarations as the intended configuration for comparison | ||
|
|
||
| **Example Scenario**: | ||
| - Your hierarchical rule targets specific VLAN configurations | ||
| - The intended configuration template doesn't include those VLANs | ||
| - The running configuration has interface declarations | ||
| - The system uses the interface lines from running config as the baseline | ||
|
|
||
| This ensures that remediation will not remove interfaces when intended configuration is empty for an interface. | ||
|
|
There was a problem hiding this comment.
Let's talk about this before pursuing further. My initial thought is this complicates things too much and going to be hard to meet everyone's POLA.
There was a problem hiding this comment.
I still feel similar, I don't fully follow the solution (examples would help), and it seems like more complication then required in a day 1 solution.
|
Think my biggest concern is the actual and intended views are
|
|
I think filtered is the whole point TBH. Compliance rules as they stand today are currently filtered if you think about it from a certain point of view - you’re matching on the parent command rather than displaying the whole intended in one screen. For example my intended config can have loads of lines which don’t have a compliance rule set and the app is happy with all the rules green. |
I understand your viewpoint; however, it shifts many other users use cases. Many people use the other config plan types for example (intended) which pulls from the compliance result. This now means its a filtered intended config-set which isn't what most users want. I think the key components are to make this work alongside all the apps features/functionalities. Where the intended and actual are still showing "everything" that matches the root/main parent, and then the missing/extra/compliance result filtered down. |
Release 2.6.1
* Added fixes * Added changelog * Added command to generate more data * Ruff fix
* Updated django-debug-toolbar version * Changelog * Apply suggestion from @smk4664 * Update poetry.lock --------- Co-authored-by: Stephen Kiely <stephenkiely87@gmail.com>
…tion-options-ltm [LTM 2.4 Backport] Fixed Hier Config Remediation Options
…g-leading-spaces-ltm [LTM 2.4 Backport] Changed compliance rule match_config to preserve leading spaces
Release v2.6.2
Release v2.6.3
Release v2.6.4
Coverage report
Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||
| for tag_rule in v3_tags: | ||
| for child in running_config.get_children_deep(tag_rule.match_rules): | ||
| child.tags_add(tag_rule.apply_tags) | ||
|
|
||
| for tag_rule in v3_tags: | ||
| for child in generated_config.get_children_deep(tag_rule.match_rules): | ||
| child.tags_add(tag_rule.apply_tags) |
There was a problem hiding this comment.
Shouldn't this be applied the same on running and generated? When does get_children_deep get applied to a running but not generated config?
11 participants
Closes: #978
What's Changed
To Do