Add Deviation clear

[henderiw]

• add the ability to clear a deviation

• New CR:

  • list of paths
    - per intent or not? -> do we allow unmanaged ?
    - wildcards? -> only at the end -> * at the end of the path,
  • delete or create ?

• Will be transacted once -> unlike a regular CR which stores the CR and triggers and event

Naming:

• ResetDeviation, ClearDeviation, ???
• UnManagedConfig

IgnoreUnManaged ?

Spec:

• name: Intent
  deviationType: config
  paths:
  • ...
• deviationType: target
  paths:
  • ...
• paths:
  • /

[steiler]

An additional aspect, I realize right now, is what I envisioned when I introduced the explicit delete flag in the protos.
Back then I realized that we do not have a means to prevent manual changes in the sense of additions to the config.
So someone manually adding config to the device that is not covered by any intent, we have no way of auto-reverting (deleting) as of now. We should have a discussion if this topic also fits in the space of this new CR.
It is somewhat different in the sense that within data-server this should result in an intent that carries the explicit-deletes, because they need to be persisted and should not be a one shot, but as a representation to the user, is might fit into this ResetDeviation / ClearDeviation space.

[steiler]

Update
After a quick discussion with @henderiw today, my understanding is, that the ResetDeviation / ClearDeviation CR will not persist, hence a combination of the two functionalities (revert specific intents as one-shots and suppression of manually added [unhandled] config) does not make sense. Hence we'll be discussing the implementation seperately.

Issue for this is #20

[henderiw]

We had some discussion on this topic and the idea so far is this.

we call this ClearDeviation or ResetDeviation

The target is indicated as we do in the config

labels:
  config.sdcio.dev/targetName: edge02
  config.sdcio.dev/targetNamespace: default

for the spec the idea is that it would be a list of items

and item contains:

• deviationType: config, target, and maybe some special once: all, allConfigs.
• if the deviationType is config, the name of the config is required
• list of paths -> which could include a wildcard

-> if the path is not found or does not match we could create a warning and or indication what happened.
-> this would be stored as the result of the instantiation of the CR.

This CR is a one shot action and the result will be stored in the apiServer. Event or exact how is TBD.

[henderiw]

I have been looking at the implementation a bit more and here is a proposal as a CRD.

/*
Copyright 2026 Nokia.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

package config

import (
	"reflect"

	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"github.com/sdcio/config-server/apis/condition"
)

type DeviationClearType string

const (
	DeviationClearType_TARGET   	DeviationClearType = "target"
	DeviationClearType_CONFIG   	DeviationClearType = "config"
	DeviationClearType_ALL_CONFIG   DeviationClearType = "allConfig"
	DeviationClearType_ALL   		DeviationClearType = "all"
)

func (r DeviationClearType) String() string {
	switch r {
	case DeviationClearType_TARGET:
		return "target"
	case DeviationClearType_CONFIG:
		return "config"
	case DeviationClearType_ALL_CONFIG:
		return "allConfig"
	case DeviationClearType_ALL:
		return "all"
	default:
		return "unknown"
	}
}

// DeviationSpec defines the desired state of Deviation
type DeviationClearSpec struct {
	Items []DeviationClearItem `json:"items" protobuf:"bytes,1,rep,name=items"`
}

type DeviationClearItem struct {
	Type DeviationClearType  `json:"type" protobuf:"bytes,1,opt,name=type"`
	// Name of the config - mandatory if the type is config - not applicable for the other types
	ConfigName *string  `json:"configName,omitempty" protobuf:"bytes,2,opt,name=configName"`
	// Paths of the respective type that should be cleared
	Paths []string `json:"paths" protobuf:"bytes,3,rep,name=paths"`
}

// DeviationStatus defines the observed state of Deviationgit
type DeviationClearStatus struct {
	// ConditionedStatus provides the status of the Readiness using conditions
	// if the condition is true the other attributes in the status are meaningful
	condition.ConditionedStatus `json:",inline" protobuf:"bytes,1,opt,name=conditionedStatus"`
}

// +genclient
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
// +kubebuilder:object:root=true
// +kubebuilder:storageversion
// +kubebuilder:subresource:status
// +kubebuilder:resource:categories={sdc}

//	DeviationClear is the Schema for the DeviationClear API
type DeviationClear struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	Spec   DeviationClearSpec   `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`
	Status DeviationClearStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
// +kubebuilder:object:root=true

// DeviationClearList contains a list of DeviationClears
type DeviationClearList struct {
	metav1.TypeMeta `json:",inline"`
	metav1.ListMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
	Items           []Deviation `json:"items" protobuf:"bytes,2,rep,name=items"`
}

// DeviationClearKind type metadata.
var (
	DeviationClearKind = reflect.TypeOf(DeviationClear{}).Name()
)

Now ideally this is implemented as a subresource on the target afais.
But otherwise we could do a clear deviation and the name should be the target.

example:

• apiVersion: config.sdcio.dev/v1alpha1
  kind: DeviationClear
  metadata:
  name:
  namespace:
  spec:
  items:
  • type: config
    name: config1
    paths:
    • /interface[name=ethernet-1/1]/description