Enforce Removal of Unhandled Configuration on Targets

[steiler]

Problem Statement

Unhandled config refers to configuration that exists on a Target but is not backed by any intent. This may be:

• Pre-existing configuration on the Target, or
• Configuration that was added out-of-band from an SDC perspective

While we are generally able to auto-revert intended configuration to its desired state, we currently have no mechanism to prevent or remove configuration that reaches the Target outside of intents.

Proposed Solution

Introduce a feature that continuously processes unhandled configuration and removes it, ensuring that the Target contains only intended configuration.

This enforcement should be configurable and scoped to specific paths, allowing some parts of the configuration tree to be protected while others remain unaffected.

Path-Based Enforcement

The proposal is to use paths per target to define the scope of enforcement. A path can represent an entire branch of the configuration tree.

Examples

/                                        # Covers the entire configuration
/interface                               # Covers everything under /interface
/interface[name=ethernet-1/1]            # Covers everything under ethernet-1/1
...

Behavior:

• If a path is specified, no additions or modifications are allowed within that path or any of its sub-paths unless backed by intent.
• All other paths remain unaffected.

Exclusions

I propose not supporting exclusions.

For example:

• If /interface is specified, there is no way to exclude /interface[name=ethernet-1/1].

This keeps the model simple and avoids ambiguity.

Implementation Details

When config-server was responsible for processing deviations, we introduced explicit-deletes in data-server.

How explicit-deletes Work

• explicit-deletes entries are added to all existing leaf entries (both leafs and leaf-lists).
• If an explicit-deletes entry has the highest precedence, it:
  • Blocks configuration from being applied to the device
  • Triggers deletion of that configuration from the Target

Proposed Approach

To ensure that only intended configuration remains on the Target:

1. Add explicit-deletes entries to the configuration tree with:

   • Higher precedence than running
   • Lower precedence than any intent

2. Tree construction flow:

   • Import all existing intents

   • Import running

   • Process explicit-deletes

     Starting from the configured path:
     - Walk the tree
     - Add explicit-deletes entries for all existing intent and running leaf variants

3. Subsequent calculations of Updates and Deletes will:

   • Take explicit-deletes into account
   • Generate the required changes to remove unhandled configuration from the Target

Outcome

This approach guarantees that, for the specified paths:

• Any configuration under the given paths, not backed by intent is automatically removed
• The Target converges to a strictly intent-driven state
• Enforcement is predictable, explicit, and easy to reason about
• Existing non-revertive intent behavior is preserved