Open bsmeding opened 3 years ago
Makes sense, after 1.0 is released, will re-evaluate.
Related to https://github.com/nautobot/nautobot/issues/896 - ComplianceRule should point to multiple Dynamic/Custom groups. This would allow for greater flexibility while defining compliance policies.
This might include:
from @mzbroch in #204
Associate ComplianceRules with GoldenConfigSetting instances.
!! This feature is dependent on implementation of #202 !!
Improve granularity, tenancy and flexibility in ComplianceRules definitions. Allow for different and multiple ComplianceRule of the same Feature Type per Platform.
Current Solution: Currently ComplianceRule of a given Feature type is associated per Platform. In more complex scenarios, users might have different ComplianceRules associated per Platform (ie. Voice routers having different AAA configuration than VPN routers)
Solution Proposal:
Associate ComplianceRule with GoldenConfigSetting object.
Introduce a name field to ComplianceRule instance.
Perform the scope definition (ie device role, tenant etc) at the GoldenConfigSetting
Preserve existing patterns:
Migration Path
default
instance of GoldenConfigSettingWill need to review design before implementation
Environment
Proposed Functionality
At this moment the complancies are based on platform, so all devices from the same platfrom are targeted to the same compliancy ruleset. Add more options to filter the targeting
Use Case
When having several Cisco IOS devices in different parts of the network, they often have other compliancy rules that needed to comply.
For example: For the Access switches (eg device role: 'access') must have TenGig1/1 and TenGig1/2 as uplink with several settings. And all access ports needs to have CDP disabled. But the distribution switches must have CDP/LLDP enables on all interfaces. This is also for security settings etc. And for devices in planned state the compliancy are minimal, disabled state does not have to apply. Also with tags for example skip check fo tag: 'development'
A minimal filter to apply to device_role and device_state will help a lot to differentiate the compliancy rules