Exclude particular labels/annotations from propagation

[ymmt2005]

What

Accurate can propagate any namespace resource between namespaces.
While copying the resource, all labels and annotations except for ones that contain kubernetes.io/ are inherited.

accurate/controllers/propagate.go

Lines 24 to 55 in ae00997

	func cloneResource(res *unstructured.Unstructured, ns string) *unstructured.Unstructured {
	c := res.DeepCopy()
	delete(c.Object, "metadata")
	delete(c.Object, "status")
	c.SetNamespace(ns)
	c.SetName(res.GetName())
	labels := make(map[string]string)
	for k, v := range res.GetLabels() {
	if strings.Contains(k, "kubernetes.io/") {
	continue
	}
	labels[k] = v
	}
	labels[constants.LabelCreatedBy] = constants.CreatedBy
	c.SetLabels(labels)
	annotations := make(map[string]string)
	for k, v := range res.GetAnnotations() {
	if strings.Contains(k, "kubernetes.io/") {
	continue
	}
	annotations[k] = v
	}
	annotations[constants.AnnFrom] = res.GetNamespace()
	c.SetAnnotations(annotations)
	// special treatment for ServiceAccount
	if c.GetAPIVersion() == "v1" && c.GetKind() == "ServiceAccount" {
	delete(c.Object, "secrets")
	}
	return c
	}

In some cases, the copied labels or annotations can cause problems.
For instance, if Argo CD is configured to track the managed resources by argocd.argoproj.io/instance label and the parent resource was created by Argo CD, the propagated resource would have the same label. Argo CD then tries to delete the propagated resource because the propagated resource is not found on the source Git repository.

So, add a feature to exclude particular labels or annotations from propagated resources.

How

Describe how to address the issue.

Checklist

• Finish implementation of the issue
• Test all functions
• Have enough logs to trace activities
• Notify developers of necessary actions

[erikgb]

@ymmt2005 Do you have any thoughts about the UX of this feature? Should it be configured:

1. globally on the controller level, excluding labels/annotations for all propagated resources
2. under watches in the controller configuration, excluding labels/annotations per resource type of propagated resources
3. new label/annotation allowing this to be configured per resource instance of propagated resources

[erikgb]

@zoetrope @ymmt2005 We are facing this issue in our clusters, and I want to fix it. Do you have some input to my question above? I think the implementation complexity will increase in order from 1 to 3. I only need this configured globally, so I'll vote for 1 - at least as a start.

[ymmt2005]

@erikgb Sorry, I didn't notice your question.

I agree with option 1.