-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Default extensions/v1beta1 Deployment's ProgressDeadlineSeconds to MaxInt32 #66581
Conversation
2b950f9
to
0fa3593
Compare
@@ -289,7 +289,8 @@ func ValidateDeploymentSpec(spec *extensions.DeploymentSpec, fldPath *field.Path | |||
} | |||
if spec.ProgressDeadlineSeconds != nil { | |||
allErrs = append(allErrs, apivalidation.ValidateNonnegativeField(int64(*spec.ProgressDeadlineSeconds), fldPath.Child("progressDeadlineSeconds"))...) | |||
if *spec.ProgressDeadlineSeconds <= spec.MinReadySeconds { | |||
if *spec.ProgressDeadlineSeconds > 0 && *spec.ProgressDeadlineSeconds <= spec.MinReadySeconds { |
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.
Is it safe to relax validation to allow 0? The API guidelines say, "Validation rules on spec fields can neither be relaxed nor strengthened."
In this case, I'm not too worried about clients being broken by 0, but what happens on the server if, for example, you roll back to a previous patch release after some objects have been persisted with a 0 value? Will the object become inaccessible? Will a "list all" fail? Or does the server handle this gracefully somehow?
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 point. Even if the object is still accessible with 0
value after downgrade, the old controller will treat deadline == 0 as "immediately pass deadline" instead of "no deadline".
It's safer to use max int instead, then.
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.
Updated to use max int32 instead.
0fa3593
to
e46e270
Compare
e46e270
to
1abd732
Compare
Doesn't this mean that anytime we have an effective default on a pointer
field, where we want to leave the field unset, we can't change the default
across versions? Pretty sure we've introduced more of these as we've
become quite pointer happy these days.
…On Tue, Jul 24, 2018 at 9:12 PM k8s-ci-robot ***@***.***> wrote:
[APPROVALNOTIFIER] This PR is *NOT APPROVED*
This pull-request has been approved by: *janetkuo
<#66581#>*
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: *lavalamp*
If they are not already assigned, you can assign the PR to them by writing /assign
@lavalamp in a comment when ready.
The full list of commands accepted by this bot can be found here
<https://go.k8s.io/bot-commands>.
The pull request process is described here
<https://git.k8s.io/community/contributors/guide/owners.md#the-code-review-process>
Needs approval from an approver in each of these files:
- *api/OWNERS
<https://github.com/kubernetes/kubernetes/blob/master/api/OWNERS>*
- *pkg/apis/OWNERS
<https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/OWNERS>*
- pkg/controller/deployment/OWNERS
<https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/deployment/OWNERS>
[janetkuo]
- *staging/src/k8s.io/api/OWNERS
<https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/OWNERS>*
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#66581 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_px-Isf0NgpgiMyDuz2lAHyBlD8jxks5uJ8XkgaJpZM4Veh72>
.
|
@smarterclayton Yes. We cannot leave a field unset in one version but defaulted in another version, because defaulting are not just applied when an object is created, but every time a serialized version is read.
I opened an umbrella issue #66582 to track other violations. |
1abd732
to
729e6de
Compare
/test pull-kubernetes-e2e-gce |
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 other than nits.
@@ -47,7 +47,7 @@ func (dc *DeploymentController) syncRolloutStatus(allRSs []*apps.ReplicaSet, new | |||
isCompleteDeployment := newStatus.Replicas == newStatus.UpdatedReplicas && currentCond != nil && currentCond.Reason == util.NewRSAvailableReason | |||
// Check for progress only if there is a progress deadline set and the latest rollout | |||
// hasn't completed yet. | |||
if d.Spec.ProgressDeadlineSeconds != nil && !isCompleteDeployment { | |||
if !util.NoProgressDeadline(d) && !isCompleteDeployment { |
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.
Nit: could we invert the function to HasProgressDeadline
to avoid the double negative?
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 point. Done.
pkg/apis/extensions/types.go
Outdated
// not be estimated during the time a deployment is paused. This is not set | ||
// by default. | ||
// not be estimated during the time a deployment is paused. This is set to | ||
// the max value of int32 (1<<31 - 1) by default, which means "no deadline". |
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.
Nit: Since this may end up in generated user docs, it might be better to give the explicit value instead (2147483647) so it looks the same way people will see it printed in objects, and so people don't need to be familiar with bit shift syntax.
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.
Done.
…xInt32. 1. MaxInt32 has the same meaning as unset, for compatibility 2. Deployment controller treats MaxInt32 the same as unset (nil)
729e6de
to
4dadbb5
Compare
@enisoc PTAL |
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
/assign @smarterclayton Would you approve it? Thanks! |
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.
nit; lgtm otherwise
@@ -330,7 +338,7 @@ func TestSyncRolloutStatus(t *testing.T) { | |||
newCond := util.GetDeploymentCondition(test.d.Status, test.conditionType) | |||
switch { | |||
case newCond == nil: | |||
if test.d.Spec.ProgressDeadlineSeconds != nil { | |||
if test.d.Spec.ProgressDeadlineSeconds != nil && *test.d.Spec.ProgressDeadlineSeconds != math.MaxInt32 { |
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.
nit: deploymentutil.HasProgressDeadline
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.
Intentionally write it explicitly in the test, so that if we break deploymentutil.HasProgressDeadline()
in the future, this test will still catch that.
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: enisoc, janetkuo, smarterclayton 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 |
/test all [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here. |
This should include a release note. @janetkuo Can you update the main PR body to include a release note? Thanks! |
Added a release note. Thanks! |
…81-upstream-release-1.11 Automated cherry pick of #66581 upstream release 1.11
What this PR does / why we need it: Default values should be set in all API versions, because defaulting happens whenever a serialized version is read. When we switched to
apps/v1
as the storage version in1.10
(#58854),extensions/v1beta1
DeploymentSpec.ProgressDeadlineSeconds
getsapps/v1
default value (600
) instead of being unset.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #66135
Special notes for your reviewer: We need to cherrypick this fix to 1.10 and 1.11. Note that this fix will only help people who haven't upgraded to 1.10 or 1.11 when the storage version is changed.
@kubernetes/sig-apps-bugs
Release note: