Story (Required)

Refactor addKubernetesData to avoid overriding external labels by replacing with a new function.

Background and Approach (Required)

The addKubernetesData function was originally introduced to ensure that Kubernetes-managed labels and annotations (e.g., scheduling, topology, or lifecycle metadata) from the live object were retained on the source object during updates. This was intended to prevent accidental loss of critical system-managed metadata.

However, it can unintentionally drop labels or annotations set by external sources such as other controllers or admission webhooks. This may result in undefined behavior for external systems relying on those metadata fields.

To address this, we will:

• Remove the addKubernetesData function.

• Replace its usage with a new helper (UpdateMapValues) that adds or updates only operator-owned metadata, without relying on or copying values from the live object.

• This ensures we retain full control over what the operator manages, while avoiding accidental removal of metadata owned by other components.

Out of Scope

• Introducing label or annotation updates to resources that currently do not have them.

Dependencies

• <Describes what this story depends on. Dependent stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

• addKubernetesData function is removed.
• All existing usages are replaced with new function
• Unit/e2e test is added.
• No changes made to resources that don’t currently use labels/annotations.

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.