fix: Preserve user changes to deployment pod templates

Fixes OLM reverting user changes like kubectl rollout restart.
OLM no longer stores pod template metadata, allowing user changes o annotations, labels, and other fields to persist.

Generate-by: Cursor/Claude

Author: camilamacedo86

internal/operator-controller/applier/boxcutter.go

@@ -12,6 +12,7 @@ import (
 	"slices"
 	"strings"
 
+	"github.com/go-logr/logr"
 	"helm.sh/helm/v3/pkg/release"
 	"helm.sh/helm/v3/pkg/storage/driver"
 	apierrors "k8s.io/apimachinery/pkg/api/errors"
@@ -153,8 +154,41 @@ func (r *SimpleRevisionGenerator) GenerateRevision(
 	return r.buildClusterExtensionRevision(objs, ext, revisionAnnotations), nil
 }
 
+// removePodTemplateMetadata removes the metadata section from a Deployment's pod template.
+// This prevents OLM from claiming ownership of pod template metadata fields via Server-Side Apply.
+func removePodTemplateMetadata(unstr *unstructured.Unstructured, l logr.Logger) {
+	if unstr.GetKind() != "Deployment" || unstr.GroupVersionKind().Group != "apps" {
+		return
+	}
+
+	obj := unstr.Object
+	spec, ok := obj["spec"].(map[string]any)
+	if !ok {
+		return
+	}
+
+	template, ok := spec["template"].(map[string]any)
+	if !ok {
+		return
+	}
+
+	// Remove the entire metadata section from pod template.
+	// This way OLM won't claim ownership of ANY pod template metadata fields.
+	if _, hasMetadata := template["metadata"]; hasMetadata {
+		delete(template, "metadata")
+		l.V(1).Info("removed pod template metadata from Deployment to preserve all user changes",
+			"deployment", unstr.GetName())
+	}
+}
+
 // sanitizedUnstructured takes an unstructured obj, removes status if present, and returns a sanitized copy containing only the allowed metadata entries set below.
 // If any unallowed entries are removed, a warning will be logged.
+//
+// For Deployment objects, this function removes the ENTIRE pod template metadata section.
+// This prevents OLM from overwriting ANY user changes to pod template metadata (annotations, labels, etc.).
+// Examples: "kubectl rollout restart", "kubectl annotate", "kubectl label", or any custom metadata users add.
+// This fixes the issue where user changes to pod templates would be undone by OLM.
+// See: https://github.com/operator-framework/operator-lifecycle-manager/issues/3392
 func sanitizedUnstructured(ctx context.Context, unstr *unstructured.Unstructured) {
 	l := log.FromContext(ctx)
 	obj := unstr.Object
@@ -193,6 +227,13 @@ func sanitizedUnstructured(ctx context.Context, unstr *unstructured.Unstructured
 		l.Info("warning: extraneous values removed from manifest metadata", "allowed metadata", allowedMetadata)
 	}
 	obj["metadata"] = metadataSanitized
+
+	// For Deployment objects, remove the ENTIRE pod template metadata section.
+	// This prevents OLM from overwriting ANY user changes to pod templates.
+	// Users can modify: annotations, labels, or any other metadata fields.
+	// Examples: kubectl rollout restart, kubectl annotate, kubectl label, etc.
+	// The deployment controller ensures required fields (like selector labels) stay in place.
+	removePodTemplateMetadata(unstr, l)
 }
 
 func (r *SimpleRevisionGenerator) buildClusterExtensionRevision(

test/e2e/features/rollout-restart.feature

@@ -0,0 +1,79 @@
+Feature: Rollout Restart User Changes
+
+  # This test checks that OLMv1 does not undo changes made by users to deployed resources.
+  # It uses "kubectl rollout restart" as an example, but the fix works for ANY pod template metadata changes.
+  #
+  # Background:
+  # - In OLMv0, user changes to pod templates (annotations, labels, etc.) would be undone by OLM.
+  # - In OLMv1, OLM should only manage the fields it owns, allowing user changes to stay.
+  #
+  # This test makes sure OLMv1 works correctly and does not have the OLMv0 problem.
+  # See: https://github.com/operator-framework/operator-lifecycle-manager/issues/3392
+
+  Background:
+    Given OLM is available
+    And ClusterCatalog "test" serves bundles
+    And ServiceAccount "olm-sa" with needed permissions is available in ${TEST_NAMESPACE}
+
+  # WHAT THIS TEST DOES:
+  # This test checks that the fix for issue #3392 works correctly.
+  # The test uses "kubectl rollout restart" as an example, but the fix is generic.
+  #
+  # THE PROBLEM (now fixed):
+  # When users changed ANY pod template metadata, Boxcutter would undo the changes:
+  #   1. User changes pod template (kubectl rollout restart, kubectl annotate, kubectl label, etc.)
+  #   2. Boxcutter runs and removes ALL user changes
+  #   3. User changes are lost
+  #
+  # THE FIX:
+  # We changed the code in applier/boxcutter.go to NOT save pod template metadata at all.
+  # This way, OLM won't overwrite ANY user changes to pod templates when it runs.
+  # Now ANY user changes to pod templates (annotations, labels, etc.) will stay in place.
+  #
+  # UPSTREAM ISSUE: https://github.com/operator-framework/operator-lifecycle-manager/issues/3392
+  @BoxcutterRuntime
+  Scenario: User-initiated deployment changes persist after OLM reconciliation
+    When ClusterExtension is applied
+      """
+      apiVersion: olm.operatorframework.io/v1
+      kind: ClusterExtension
+      metadata:
+        name: ${NAME}
+      spec:
+        namespace: ${TEST_NAMESPACE}
+        serviceAccount:
+          name: olm-sa
+        source:
+          sourceType: Catalog
+          catalog:
+            packageName: test
+            selector:
+              matchLabels:
+                "olm.operatorframework.io/metadata.name": test-catalog
+      """
+    Then ClusterExtension is rolled out
+    And ClusterExtension is available
+    And resource "deployment/test-operator" is installed
+    And deployment "test-operator" is ready
+
+    # User runs "kubectl rollout restart deployment/test-operator"
+    # This adds a restart annotation to trigger a rolling restart of pods.
+    # Note: This test uses restart as an example, but the fix works for ANY pod template metadata changes.
+    # In OLMv0, OLM would undo this change and stop the rollout.
+    # In OLMv1, the change should stay because kubectl owns it.
+    When user performs rollout restart on "deployment/test-operator"
+
+    # Wait for the rollout to finish - new pods created and running
+    Then deployment "test-operator" rollout completes successfully
+    And resource "deployment/test-operator" has restart annotation
+
+    # Wait for OLM to run its checks (OLM checks every 10 seconds)
+    # This is the important part: does OLM undo what the user did?
+    And I wait for "30" seconds
+
+    # After OLM runs, check that the rollout is STILL working
+    # In OLMv0, this would fail because OLM undoes the annotation
+    # and the new pods would be stopped and old pods would come back
+    Then deployment "test-operator" rollout is still successful
+    And resource "deployment/test-operator" has restart annotation
+    And deployment "test-operator" has expected number of ready replicas