-
Notifications
You must be signed in to change notification settings - Fork 752
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
fix the default value of imagePullPolicy #1275
Conversation
…t value of imagePullPolicy
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Welcome @ktalg! It looks like this is your first PR to openkruise/kruise 🎉 |
@@ -1,9 +1,9 @@ | |||
package mutating | |||
|
|||
import ( | |||
"github.com/openkruise/kruise/apis/apps/defaults" |
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.
goimports: File is not goimports
-ed
ℹ️ Expand to see all @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
Command | Usage |
---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #1275 +/- ##
==========================================
- Coverage 48.45% 48.43% -0.02%
==========================================
Files 149 149
Lines 20627 20634 +7
==========================================
Hits 9994 9994
- Misses 9537 9544 +7
Partials 1096 1096
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@ktalg Thank you very much, I have tried to understand this issue. I feel that the core of this problem is that modifying the Image also changes the ImagePullPolicy field, which prevents in-place upgrades from continuing. This is indeed quite strange, but we cannot fix it in this way, because if the user has really made changes to the ImagePullPolicy field, we cannot simply reuse the old value. If we don't use the SetDefaults_Container function, it's not very reasonable. My opinion right now is to explicitly declare the ImagePullPolicy field to avoid this issue. |
This pr does cause some logical changes, but I don't think it causes the problem you are talking about, because it is a setting of the default value of ImagePullPolicy, which only takes effect when it is empty (just like the setting of the default value of other fields, which only works on empty values).Of course, this behavior does not take effect for newly created objects If the user does not explicitly set the ImagePullPolicy when updating (not creating) the object, then we do not treat the "not set" action of this field as "set to empty" but rather we need to set This field needs to be set to a reasonable value(again, just like any other field), I think it should be the old value and not the value determined by the image tag (which raises unexpected cases and is not reasonable) (If I'm missing something, please point it out) |
@ktalg I'm just thinking, it seems a bit strange to me. Additionally, we have changed the default value for ImagePullPolicy in k8s, and I'm not sure if that could bring up new issues. |
After confirming that this change is work, let me clarify the possible undesired side effects it can cause and the scenarios where it happens:
The conditions for the above to happen are so harsh that it seems we can assume that the user would not expect ImagePullPolicy to be affected by the image tag - the above side effect should not have happened |
@ktalg You have considered things very comprehensively, but my concerns are as follows:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Ⅰ. Describe what this PR does
Fixed an issue that caused sidecarset in-place update to not work in some scenarios
Ⅱ. Does this pull request fix one issue?
fix #1270
Ⅲ. Describe how to verify it
just see the unit test
Ⅳ. Special notes for reviews
The setting of default value of the container's imagePullPolicy in sidecarSet is affected by the image tag , which makes it possible to change the value of SidecarSetHashWithoutImage even if only the image tag is modified, thus making the in-place upgrade of the container ineffective.