-
Notifications
You must be signed in to change notification settings - Fork 883
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduced a lazy activation preference to PropagationPolicy/ClusterPropagationPolicy #4577
Conversation
5f670d7
to
6ee6598
Compare
Codecov ReportAttention:
❗ 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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
523bdd5
to
b6ac7e3
Compare
205c5e5
to
73b77ae
Compare
Signed-off-by: chaosi-zju <chaosi@zju.edu.cn>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[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:
Approvers can indicate their approval by writing |
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
|
I think this may because the detail resource applied in order, just like: configmap --> pp --> deploy our principle is 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. |
If you use If the pp and resource are all not exist, 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 resource in waiting list can also has |
It's really difficult for users. |
Is there a compromise? |
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?: