Device_redundancy_groups, bad data, and intended config

[auuecker]

Environment

• Nautobot version (Docker tag too if applicable): 2.2.3
• Python version: 3.10
• Database platform, version:
• Middleware(s):

Steps to Reproduce

1. Build config_context where it filters based on device_redundancy_groups as shown in example above but provide some variables for a template file to build an intended config
2. have a template that uses the config_context to build intended config
3. make sure that at least one of the device_redundancy_groups doesn't exist in nautobot, I receive an error like this in nautobot: Error in loading config context data from datacenter-junos_fw-logging_west.yml: No matching DeviceRedundancyGroup found for {'name': example1voice'}; unable to create/update context Datacenter Juniper Firewall West Logging
4. have nautobot build intended config.

Expected Behavior

Expected behavior would be for there to be no intended config for example1voice devices in the device_redundancy_groups but I should have intended config built for example2video devices in that device_redundancy_groups

Observed Behavior

The observed behavior is that because example1voice device_redundancy_group doesn't exist then not devices in any of the filtered for device_redundancy_groups have their intended config build even if say example2video device_redundancy_groups does exist.

[glennmatthews]

I'm not certain I fully understand the issue reported here, but the mention of build intended config suggests that this may be a golden-config issue rather than a nautobot core issue?

[lampwins]

We don't want to support this type of behaviour because it does not meet the principal of a least surprise. If there are multiple config context records, I could see partially loading them if there are errors in some, but not partially loading an individual record that references non-existent data.

[auuecker]

Just saw these comments I apologize, I do not use github very often. My issue is that if a device_redundancy_group that i describe as a filter does not have any data for it or it doesn't exist yet then all my other device_redunancy_group devices do not have their intended configs built because then the config_context variables break. I do not think that this should be the case. Just like if i have a role defined for a group of devices and i have multiple roles as the filters for a specific config_context I wouldnt want that config_context section to break for all roles that are being filtered for, just because one role I defined doesn't exist yet. But is there a reason for making the config_context break for all filtered devices rather than just the ones that don't exist?

The observed behavior is that because example1voice device_redundancy_group doesn't exist then not devices in any of the filtered for device_redundancy_groups have their intended config build even if say example2video device_redundancy_groups does exist.