chore(e2e): add e2e test for non graceful node shutdown #111380
Conversation
|
@sonasingh46: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
|
Hi @sonasingh46. 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 Once the patch is verified, the new status will be reflected by the 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. |
|
/ok-to-test |
|
/assign |
|
/assign |
|
/assign |
| ginkgo.It("should get immediately rescheduled to a different node after non graceful node shutdown ", func() { | ||
| // Install gce pd csi driver | ||
| ginkgo.By("deploying csi gce-pd driver") | ||
| driver := drivers.InitGcePDCSIDriver() |
There was a problem hiding this comment.
Can we have this test for Hostpath CSI driver as well?
See this: https://github.com/kubernetes/kubernetes/blob/master/test/e2e/storage/csi_volumes.go#L30-L31
There was a problem hiding this comment.
yeah, hostpath driver test is kind of must in this case.
There was a problem hiding this comment.
@humblec -- Sure. I need to understand more on why and what cases it covers.
For hostpath, the hostpath csi driver and the application pod needs to reside on the same node. Once we shut down a node non gracefully -- the hostpath csi driver will be stuck in pending state due to node affinity requirements. Even if we patch the hostpath csi driver to make it run on a different node -- the application pod using the pv will be in pending state because of the node affinity rule that is wired into the PV. That means we use altogether a new PVC to get the application pod running again on a different node -- which I think will defeat the purpose of test.
Am I missing something, or there could be a way to test?
a2c34e0 to
792a169
Compare
|
|
||
| ginkgo.Describe("NonGracefulNodeShutdown", func() { | ||
| ginkgo.Context("pod that uses a persistent volume via gce pd driver", func() { | ||
| ginkgo.It("should get immediately rescheduled to a different node after non graceful node shutdown ", func() { |
There was a problem hiding this comment.
We generally use Context block only when we want to isolate our test suite in different contexts, since this test has only one, may be we don't need one.
|
/retest |
|
Can you squash the commits? |
Signed-off-by: Ashutosh Kumar <sonasingh46@gmail.com>
3ed3629 to
707d50d
Compare
Done |
|
/retest |
|
/lgtm |
|
/assign @pohly |
Signed-off-by: Ashutosh Kumar <sonasingh46@gmail.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gnufied, sonasingh46 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 |
|
/retest |
|
/lgtm |
Signed-off-by: Ashutosh Kumar sonasingh46@gmail.com
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR adds e2e test for non graceful shutdown of the node.
Ref:
Blog Link: https://kubernetes.io/blog/2022/05/20/kubernetes-1-24-non-graceful-node-shutdown-alpha/
Feature PR Link: #108486
Issue Link : kubernetes/enhancements#2268
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: