ClaimMetadata not properly cleaned on deletion of Lazy activationPreference propagationpolicy

[zhzhuang-zju]

What happened:
When I first deploy a Deployment and then deploy a PropagationPolicy with Lazy activationPreference, no corresponding ResourceBinding is generated. This is normal.
However, if I then delete this PropagationPolicy, the Deployment still retains the PropagationPolicy-related labels and metadata. Subsequently, when I deploy a new PropagationPolicy with a non-Lazy activationPreference, the Deployment fails to match this newly created PropagationPolicy.

What you expected to happen:
When a PropagationPolicy with Lazy activationPreference is deleted, the ClaimMetadata should be properly cleaned up so that it does not prevent the Resource Template from binding to a new PropagationPolicy.

How to reproduce it (as minimally and precisely as possible):

1. Set up a Karmada environment:

$ hack/local-up-karmada.sh

2. Deploy a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx

3. Deploy a PropagationPolicy with Lazy activationPreference:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  activationPreference: Lazy
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
  placement:
    clusterAffinity:
      clusterNames:
      - member1
      - member2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
        - targetCluster:
            clusterNames:
            - member1
          weight: 1
        - targetCluster:
            clusterNames:
            - member2
          weight: 1

At this point, no ResourceBinding is generated, and the Deployment already has PropagationPolicy-related ClaimMetadata:

  annotations:
    propagationpolicy.karmada.io/name: nginx-propagation
    propagationpolicy.karmada.io/namespace: default
  labels:
    app: nginx
    propagationpolicy.karmada.io/permanent-id: 537816cb-e95b-45ca-96c8-e7d5cfadae6e

4. Delete the PropagationPolicy with Lazy activationPreference:
   The Deployment still retains the PropagationPolicy-related ClaimMetadata.

5. Deploy a new PropagationPolicy with non-Lazy activationPreference:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation-new
spec:
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
  placement:
    clusterAffinity:
      clusterNames:
      - member1
      - member2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
        - targetCluster:
            clusterNames:
            - member1
          weight: 1
        - targetCluster:
            clusterNames:
            - member2
          weight: 1

At this point, the Deployment does not bind to the new PropagationPolicy to generate a ResourceBinding.

Anything else we need to know?:

• Note: The issue described above only occurs when you first deploy a Deployment and then deploy a PropagationPolicy with Lazy activationPreference.

• Root Cause: When a PropagationPolicy is deleted, the detector uses the PropagationPolicy-related labels to list ResourceBindings first. It then looks up the ResourceTemplate based on resourcebindingSpec.Resource to clean up the PropagationPolicy-related ClaimMetadata on both the ResourceTemplate and ResourceBinding. The process is illustrated below:

However, if you first deploy a Deployment and then a PropagationPolicy with Lazy activationPreference, no ResourceBinding is generated. As a result, during the cleanup process for PropagationPolicy-related ClaimMetadata, the ResourceTemplate is overlooked, leading to residual metadata.

Environment:

• Karmada version:
• kubectl-karmada or karmadactl version (the result of kubectl-karmada version or karmadactl version):
• Others: