Increase tolerance of CO's not reporting Progressing #30602
Conversation
We found sometimes in CI that the CVO's waiting is timed out because Kubelet is slow, e.g. `45s`, to get a running pod for the target version of the component's deployment. CVO should not include the time there because it is out of the control of component. However, it is challenging to exclude it in the current CVO's implementation. The original timeout `2m` was there up to CVO's batching strategy (only once in `1m`) to update CVO's status for which the component should not be responsible. This pull adjusts it to `3m` for the slow Kubelet actions. The adjustment is only a temporary measure as we do not know how slow it could be for Kubelet such as pulling an image for the deployment. Thus, the ideal solution for the issue here is that CVO figures out how to measure the timing precisely. For now, the compromise is this pull.
|
Pipeline controller notification For optional jobs, comment This repository is configured in: automatic mode |
|
Scheduling required tests: |
|
/test e2e-aws-ovn-fips |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hongkailiu, wking, xueqzhan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/label acknowledge-critical-fixes-only |
openshift-ci
bot
added
the
acknowledge-critical-fixes-only
|
/retest-required |
|
@hongkailiu: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
|
/cc |
5 participants
We found sometimes in CI that the CVO's waiting is timed out because Kubelet is slow, e.g.
45s, to get a running pod for the target version of the component's deployment.CVO should not include the time there because it is out of the control of component. However, it is challenging to exclude it in the current CVO's implementation.
The original timeout
2mwas there up to CVO's batching strategy (only once in1m) to update CVO's status for which the component should not be responsible. This pull adjusts it to3mfor the slow Kubelet actions.The adjustment is only a temporary measure as we do not know how slow it could be for Kubelet such as pulling an image for the deployment. Thus, the ideal solution for the issue here is that CVO figures out how to measure the timing precisely. For now, the compromise is this pull.