Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: When a resource is created for the first time, it should also be considred as a modification. #4583
base: master
Are you sure you want to change the base?
feat: When a resource is created for the first time, it should also be considred as a modification. #4583
Changes from all commits
0028f79
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
/cc @RainbowMango @chaosi-zju
My core idea is: Whether PP is Lazy or immediate, it should be immediate when the resources have not yet been bound by PP.
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.
I believe
Lazy
should only take effect after the PP is bound with resources.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.
does this PR want to resolve the problem #4577 (comment) you memtioned here?
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.
No, these are two different issues.
The issue in Introduced a lazy activation preference to PropagationPolicy/ClusterPropagationPolicy #4577 (comment) is that using a single PP to select two resources with different effects.
This PR wants to introduce "Lazy should only take effect after the PP is bound with resources."
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.
Assuming that a resource has been distributed according to PolicyA.
Then PolicyA deleted, or changed
resourceSelector
and no longer match to the resource.The detecor will remove the
policy label
in resource immediately.This will also triggle resoure updated.
In this case, resouce will look for a new policy (PolicyB), if PolicyB is
Lazy
, the binding should be unchanged.The related pods of the reosource running just fine, we shouldn't break it just because policy change.
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.
Good question, your question introduces a new thought, whether the binding of PP and resources is
Lazy
orImmediate
.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.
This principle is what I want too, and I couldn't agree more.
However, there is an ambiguity in our understanding of
buond
. I understandbound
to mean that a resource is bound when it islabelled
with a policy, whereas you think that a resource is bound when it is refreshed with a binding following a policy.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.
So the core of my proposal is
The impact of Policy changes on the bondage relationship between resources and Policy is always immediate, but whether the resource needs to synchronize the latest placement to the binding immediately is determined by this field.
Pay attention to
the bondage relationship between resources and Policy is always immediate
, when a resource is labelled with a policy, just finish label, it finished thebound
.after
bound
, there's only ever one definitive policy for this resource, if this policy islazy
, don't change the resource's binding.This would be the clearest behaviour.
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.
I got you.
However, most resources, once created, will not be changed.
As i said: