Apply_mode: setting to differentiate between directly applied configlets and ones inherited from containers

[tonybourkesdnpros]

Enhancement summary

This was an issue I found in #400

When using apply_mode: strict for cv_device_v3, configlets that aren't mentioned in the list for a device are removed (which is good). But so are any configlets that are inherited from the containers. Sometimes this is good, but sometimes this is bad if you want to use configlets applied to both containers and devices.

I can get around this by invoking devices_v3 first, and containers_v3 after it. But sometimes that means I have to run containers_v3 both before and after (once to setup the container archticture, then to assign configlets, and again to re-add the configlets inherited from containers that were removed from apply_mode: strict).

Which component of AVD is impacted

cv_device_v3

Use case example

For a playbook that acts like a "genesis torpedo" (Star Trek II reference), where by whatever configlets are on the containers and devices are replaced entirely with the variables in a YAML file, I use strict mode for cv_device_v3.

This is especially good in demos and lab environments, where we want to make sure the vestiges of the last configuration are wiped out in favor of the new arrangement (or in production where we want the YAML file used by cv_device_v3, cv_container_v3, cv_configlet_v3 to be the sole source of configuration truth).

Some container/device topologies benefit from using configlets applied to containers versus directly on devices, but that doesn't work when using apply_mode: strict.

Describe the solution you'd like

A setting for apply_mode: (similar to strict) which allows container-added configlets to remain.

Describe alternatives you've considered

There are two workarounds:

• Just apply configlets only to devices.
• Run the cv_containter_v3 task twice. Once before cv_device_v3, and once after.

Both work, but neither seem ideal.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days