Code changes for Probe-level Termination Grace Period Beta #103168

raisaat · 2021-06-24T23:10:40Z

What type of PR is this?

/kind feature
/sig node
/priority important-soon

What this PR does / why we need it:

Code changes to graduate this KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period to beta

Move feature flag to beta, leave as false
Remove feature gate from kubelet
Add validation to ensure terminationGracePeriodSeconds is non-negative
- Fix TerminationGracePeriodSeconds is negative (part 1) #98866
- Add validation for Prober TerminationGracePeriodSeconds #103245

Which issue(s) this PR fixes:

KEP issue: kubernetes/enhancements#2238

Special notes for your reviewer:

Does this PR introduce a user-facing change?

ACTION REQUIRED: Removed the feature flag for probe-level termination grace period from Kubelet. If a user wants to disable this feature on already created pods, they will have to delete and recreate the pods.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period

k8s-ci-robot · 2021-06-24T23:10:44Z

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

k8s-ci-robot · 2021-06-24T23:10:48Z

Welcome @raisaat!

It looks like this is your first PR to kubernetes/kubernetes 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubernetes has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

k8s-ci-robot · 2021-06-24T23:10:49Z

Hi @raisaat. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

ehashman · 2021-06-24T23:13:04Z

Please make sure you sign the CLA: #103168 (comment)

ehashman

/sig node
/priority important-soon
/triage accepted

Per https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period#beta-122 we still need to do the following:

Move feature flag to beta, leave as false
Remove feature gate from kubelet
Ensure that when feature gate is off in API server, probe-level TerminationGracePeriodSeconds is blanked out.
Add validation to ensure terminationGracePeriodSeconds is non-negative. -> see Fix TerminationGracePeriodSeconds is negative (part 1) #98866

ehashman · 2021-06-24T23:24:43Z

pkg/api/pod/util_test.go

+						// new pod should not have grace period if the feature gate is disabled
+						t.Errorf("new pod should not have grace period if the feature is disabled")
+
+					case reflect.DeepEqual(newPod, newPodInfo.pod()):


This doesn't make sense to me as a case. We're unconditionally evaluating this if the first two cases don't happen, and if it's true, throwing an error. Whether they're equal is a test outcome, not a dev expectation. But, this is also opposite to the default case below, so I think this was just an oversight.

We need a case for oldPodHasGracePeriod to assert that the field was dropped. I'd suggest we repurpose this case for that.

Test matrix is

Feature flag is on:

Pod has grace period: unchanged

Pod does not have grace period: unchanged

Feature flag is off:

Pod has grace period: should be dropped

Pod does not have grace period: unchanged

Thus, I'd expect our cases to be:

if enabled || !oldPodHasGracePeriod: should be unchanged

Now we know it's disabled. So, we should check next, if !enabled && newPodHasGracePeriod and ensure the field is blanked out (note: it is probably clearer to write it the way I've written in this comment rather than trying to be clever with boolean logic)

if !enabled && oldHasGracePeriod: should be dropped -- need a case for this still

I think we can keep the default case below as written unchanged.

ehashman · 2021-06-24T23:27:35Z

/test pull-kubernetes-verify
/test pull-kubernetes-unit

raisaat · 2021-06-28T14:15:22Z

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.

If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.

If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/

Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I signed the CLA

ehashman · 2021-06-28T20:44:00Z

/check-cla

raisaat · 2021-06-29T16:23:40Z

pkg/api/pod/util_test.go

-					// new pod should not have subpaths
-					if !reflect.DeepEqual(newPod, podWithoutProbeGracePeriod()) {
-						t.Errorf("new pod had probe-level terminationGracePeriod: %v", cmp.Diff(newPod, podWithoutProbeGracePeriod()))
+					dropDisabledFields(&newPod.Spec, nil, oldPodSpec, nil)


newPod and newPodInfo.pod() should be different after the feature is disabled and the feature is dropped via the dropDisabledFields function with the dropDisabledFields function written as is right now, right? The reason is that the dropDisabledFields function blanks out the LivenessProbe.TerminationGracePeriodSeconds and StartupProbe.TerminationGracePeriodSeconds fields of the containers in newPod while newPodInfo.pod() remains unchanged. So reflect.DeepEqual(newPod, newPodInfo.pod()) should return a false for the condition if !enabled && newPodHasGracePeriod, right? Trying to figure out why it returns true instead.

What you're discussing here should be covered by the case newPodHasGracePeriod: below, no?

If I throw an error directly for case newPodHasGracePeriod, 5 test cases fail. So I tried adding if reflect.DeepEqual(newPod, newPodInfo.pod()) under case newPodHasGracePeriod and a t.Errorf under that if condition. The 5 test cases fail for the latter as well.

raisaat · 2021-06-29T23:03:57Z

pkg/api/pod/util_test.go

 				if newPod == nil {
 					continue
 				}

 				t.Run(fmt.Sprintf("feature enabled=%v, old pod %v, new pod %v", enabled, oldPodInfo.description, newPodInfo.description), func(t *testing.T) {
-
 					defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.ProbeTerminationGracePeriod, enabled)()


left this line and the for loop for enabling/disabling the feature unchanged (discarded all the other changes I had made in the previous commits). The test cases where the feature flag is disabled and the newPod has a probe-level termination grace period are still failing.

ehashman · 2021-06-30T18:05:36Z

/test pull-kubernetes-unit

raisaat · 2021-06-30T18:27:21Z

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.

If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.

If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/

Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

ehashman

/lgtm

liggitt · 2021-07-13T00:04:12Z

API bits lgtm

/approve
/hold for #103245 to merge first and for application of milestone

liggitt · 2021-07-13T00:04:16Z

/retest

k8s-ci-robot · 2021-07-13T00:04:31Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ehashman, liggitt, mrunalp, raisaat

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:

~~api/OWNERS~~ [liggitt]
~~pkg/apis/OWNERS~~ [liggitt]
~~pkg/features/OWNERS~~ [ehashman,liggitt]
~~pkg/kubelet/OWNERS~~ [liggitt,mrunalp]
~~staging/src/k8s.io/api/OWNERS~~ [liggitt]

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

JamesLaverack · 2021-07-13T14:15:03Z

/milestone v1.22

ehashman · 2021-07-13T16:52:50Z

Looks like this needs a rebase...

… flag from Kubelet

ehashman

/lgtm
assuming CI passes

/hold cancel

k8s-ci-robot added cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jun 24, 2021

k8s-ci-robot requested review from smarterclayton and thockin June 24, 2021 23:10

k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jun 24, 2021

k8s-ci-robot added needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jun 24, 2021

ehashman reviewed Jun 24, 2021

View reviewed changes

raisaat commented Jun 29, 2021

View reviewed changes

ehashman reviewed Jul 12, 2021

View reviewed changes

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 12, 2021

liggitt self-assigned this Jul 12, 2021

k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 13, 2021

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 13, 2021

k8s-ci-robot added this to the v1.22 milestone Jul 13, 2021

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 13, 2021

raisaat force-pushed the beta-2238 branch from 1d786a7 to 7d37fd4 Compare July 13, 2021 17:15

k8s-ci-robot removed lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Jul 13, 2021

raisaat force-pushed the beta-2238 branch 2 times, most recently from 3251fce to 1d786a7 Compare July 13, 2021 17:50

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 13, 2021

raisaat and others added 2 commits July 13, 2021 14:25

Move feature flag to beta (but leave as false) and remove the feature…

bf2ae14

… flag from Kubelet

Update API description for probe.terminationGracePeriodSeconds

aaa7de0

raisaat force-pushed the beta-2238 branch from 1d786a7 to aaa7de0 Compare July 13, 2021 19:29

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 13, 2021

ehashman reviewed Jul 13, 2021

View reviewed changes

k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. and removed do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. labels Jul 13, 2021

k8s-ci-robot merged commit f0b7ad3 into kubernetes:master Jul 13, 2021

tengqm mentioned this pull request Jul 18, 2021

Batch update feature gates for 1.22 kubernetes/website#28849

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Code changes for Probe-level Termination Grace Period Beta #103168

Code changes for Probe-level Termination Grace Period Beta #103168

raisaat commented Jun 24, 2021 •

edited

Loading

k8s-ci-robot commented Jun 24, 2021

k8s-ci-robot commented Jun 24, 2021

k8s-ci-robot commented Jun 24, 2021

ehashman commented Jun 24, 2021

ehashman left a comment

ehashman Jun 24, 2021

ehashman commented Jun 24, 2021

raisaat commented Jun 28, 2021

ehashman commented Jun 28, 2021

raisaat Jun 29, 2021 •

edited

Loading

ehashman Jun 29, 2021

raisaat Jun 29, 2021

raisaat Jun 29, 2021 •

edited

Loading

ehashman commented Jun 30, 2021

raisaat commented Jun 30, 2021

ehashman left a comment

liggitt commented Jul 13, 2021

liggitt commented Jul 13, 2021

k8s-ci-robot commented Jul 13, 2021

JamesLaverack commented Jul 13, 2021

ehashman commented Jul 13, 2021

ehashman left a comment

Code changes for Probe-level Termination Grace Period Beta #103168

Code changes for Probe-level Termination Grace Period Beta #103168

Conversation

raisaat commented Jun 24, 2021 • edited Loading

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

k8s-ci-robot commented Jun 24, 2021

k8s-ci-robot commented Jun 24, 2021

k8s-ci-robot commented Jun 24, 2021

ehashman commented Jun 24, 2021

ehashman left a comment

Choose a reason for hiding this comment

ehashman Jun 24, 2021

Choose a reason for hiding this comment

ehashman commented Jun 24, 2021

raisaat commented Jun 28, 2021

ehashman commented Jun 28, 2021

raisaat Jun 29, 2021 • edited Loading

Choose a reason for hiding this comment

ehashman Jun 29, 2021

Choose a reason for hiding this comment

raisaat Jun 29, 2021

Choose a reason for hiding this comment

raisaat Jun 29, 2021 • edited Loading

Choose a reason for hiding this comment

ehashman commented Jun 30, 2021

raisaat commented Jun 30, 2021

ehashman left a comment

Choose a reason for hiding this comment

liggitt commented Jul 13, 2021

liggitt commented Jul 13, 2021

k8s-ci-robot commented Jul 13, 2021

JamesLaverack commented Jul 13, 2021

ehashman commented Jul 13, 2021

ehashman left a comment

Choose a reason for hiding this comment

raisaat commented Jun 24, 2021 •

edited

Loading

raisaat Jun 29, 2021 •

edited

Loading

raisaat Jun 29, 2021 •

edited

Loading