Introduced a lazy activation preference to PropagationPolicy/ClusterPropagationPolicy

[chaosi-zju]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Introduced a lazy activation preference to PropagationPolicy/ClusterPropagationPolicy.

ActivationPreference indicates how the referencing resource template will be propagated, in case of policy changes.

If empty, the resource template will respond to policy changes immediately, in other words, any policy changes will drive the resource template to be propagated immediately as per the current propagation rules.

If the value is 'Lazy' means the policy changes will not take effect for now but defer to the resource template changes, in other words, the resource template will not be propagated as per the current propagation rules until there is an update on it.

This is an experimental feature that might help in a scenario where a policy manages huge amount of resource templates, changes to a policy typically affect numerous applications simultaneously. A minor misconfiguration could lead to widespread failures. With this feature, the change can be gradually rolled out through iterative modifications of resource templates.

More info refer to #4563

Which issue(s) this PR fixes:

Fixes part of #4563

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Introduced a lazy activation preference to PropagationPolicy/ClusterPropagationPolicy.

[chaosi-zju]

CC @RainbowMango @XiShanYongYe-Chang

[codecov-commenter]

Codecov Report

Attention: 112 lines in your changes are missing coverage. Please review.

Comparison is base (f054313) 51.89% compared to head (926e34a) 51.69%.
Report is 10 commits behind head on master.

Files	Patch %	Lines
pkg/detector/detector.go	0.00%	43 Missing ⚠️
pkg/util/eventfilter/eventfilter.go	9.75%	37 Missing ⚠️
pkg/detector/handler.go	0.00%	14 Missing ⚠️
pkg/detector/policy.go	0.00%	9 Missing ⚠️
pkg/util/policy.go	0.00%	5 Missing ⚠️
pkg/util/fedinformer/keys/keys.go	0.00%	2 Missing ⚠️
pkg/util/fedinformer/handlers.go	0.00%	1 Missing ⚠️
pkg/util/worker.go	50.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4577      +/-   ##
==========================================
- Coverage   51.89%   51.69%   -0.21%     
==========================================
  Files         246      247       +1     
  Lines       24328    24418      +90     
==========================================
- Hits        12626    12623       -3     
- Misses      11016    11107      +91     
- Partials      686      688       +2     

Flag	Coverage Δ
unittests	51.69% <4.27%> (-0.21%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[RainbowMango]

/lgtm
/approve

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [RainbowMango]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[chaunceyjiang]

I found that deployment behaves differently from configMap. When I use the following PP, the deployment can propagate to member clusters, but the configMap cannot.

Note: Only apply this file.

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  activationPreference: Lazy
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
    - apiVersion: v1
      kind: ConfigMap
      name: game-demo
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - member1
            weight: 1
          - targetCluster:
              clusterNames:
                - member2
            weight: 1
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # property-like keys; each key maps to a simple value
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

  # file-like keys
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
---
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

[chaosi-zju]

I found that deployment behaves differently from configMap. When I use the following PP, the deployment can propagate to member clusters, but the configMap cannot.

I think this may because the detail resource applied in order, just like: configmap --> pp --> deploy

our principle is creation/updation/deletion of pp shouldn't actively triggle the propagation change of the resource. So:

If the resource create before pp, after pp created, the resource keep unchanged.

If the pp create before resource, after resource created, the resource propagated by the pp.

[chaosi-zju]

I found that deployment behaves differently from configMap. When I use the following PP, the deployment can propagate to member clusters, but the configMap cannot.

If you use Lazy policy, you should understand PropagationPolicy is a preconfigured policy.

If the pp and resource are all not exist, you should apply pp first, then to apply resource.

[chaunceyjiang]

you should apply pp first, then to apply resource.

So, I think this is the issue, it requires users to perceive the apply order forcibly. Obviously, in a real-world environment, it's hard for us to determine the create order of users.

[chaosi-zju]

you should apply pp first, then to apply resource.

So, I think this is the issue, it requires users to perceive the apply order forcibly. Obviously, in a real-world environment, it's hard for us to determine the create order of users.

yes, lazy policy should apply before resource.

when lazy policy created, it will not triggle resource in waiting list to refresh binding (it only triggle ClaimPolicyForObject to establish boundge relationship, but not triggle CreateOrUpdateResourceBinding) （it seems that you want it do this）

resource in waiting list can also has ResourceBiding and Work, the related pods running just fine, creation of lazy policy shouldn't change its propagation states.

[chaunceyjiang]

yes, lazy policy should apply before resource.

It's really difficult for users.

[chaosi-zju]

It's really difficult for users.

Is there a compromise?