Retry clone kill which is flaky #1950
Conversation
kubevirt-bot
added
release-note-none
|
/hold |
kubevirt-bot
added
the
do-not-merge/hold
|
/test all |
There was a problem hiding this comment.
line 1319:
err = utils.WaitTimeoutForPodReady(f.K8sClient, utils.UploadPodName(targetPvc), targetNs.Name, utils.PodWaitForTime)
This wait has polling interval set to 2 seconds. So, in worst case, it can miss any action that has finished in 2 seconds. I think in good conditions our upload server can handle tinyCoreIso in milliseconds.
[test_id:4000] Create a data volume and then clone it while killing the container and verify retry count was pretty flaky lately. It was failing on attempting to connect to the upload server pod to kill it. This PR causes a retry. Signed-off-by: Alexander Wels <awels@redhat.com>
to kill the process Signed-off-by: Alexander Wels <awels@redhat.com>
awels
force-pushed
the
fix_cloner_retry_test
branch
from
38a3edf
to
6ce07d7
Compare
Signed-off-by: Alexander Wels <awels@redhat.com>
awels
force-pushed
the
fix_cloner_retry_test
branch
from
6ce07d7
to
2d604b6
Compare
|
/retest |
|
/test all |
|
hpp destructive has a problem in before each, looks like it cannot find CDI
/test all |
|
/retest |
|
/test all |
|
Yeah the destructive lane has a flake where it sometimes messes up the cdi object, which is one of the main reasons we put it in a separate lane to start with. I am mainly interested in seeing several runs where the clone test that is failing often right now doesn't fail. |
|
/test pull-containerized-data-importer-e2e-k8s-1.19-ceph |
|
/hold cancel |
kubevirt-bot
removed
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awels 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 |
kubevirt-bot
added
the
approved
|
/lgtm |
|
/retest |
Signed-off-by: Alexander Wels awels@redhat.com
What this PR does / why we need it:
[test_id:4000] Create a data volume and then clone it while killing the
container and verify retry count was pretty flaky lately. The likely culprit was the small amount of data being cloned. This causes the pods to be removed before we have a chance to connect issue the kill command.
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 #
Special notes for your reviewer:
Release note: