update cri proxy timeout to 2h

[pacoxu]

• add a evented pleg e2e test kubernetes#128258
• [node-e2e] add test cases for serialize and parallel image pulling kubernetes#121604

Plan to add more test cases in this CI.

[pacoxu]

/assign @SergeyKanzhelev

[SergeyKanzhelev]

Is this to accomodate evented PLEG tests?

[pacoxu]

Is this to accommodate Evented PLEG tests?

Yes, for both evented PLEG and generic PLEG tests. I’m aiming to include most test cases initially, with plans to simplify and merge them where possible.

The duration is currently longer because most EventedPLEG tests fail after timing out. Once all test cases pass, the overall time should decrease.

[SergeyKanzhelev]

Yes, for both evented PLEG and generic PLEG tests. I’m aiming to include most test cases initially, with plans to simplify and merge them where possible.

Why will we need all PLEG tests running with cri proxy? It will make them all serialized and will slow down other tests. Can we only run a subset of PLEG tests with CRI proxy?

[pacoxu]

Yes, for both evented PLEG and generic PLEG tests. I’m aiming to include most test cases initially, with plans to simplify and merge them where possible.

Why will we need all PLEG tests running with cri proxy? It will make them all serialized and will slow down other tests. Can we only run a subset of PLEG tests with CRI proxy?

cri-proxy can mock many special CRI failures which should be handled by PLEG.

As PLEG issues are not easy to reproduce and track in CI, this may help us to avoid regression in PLEG.

[SergeyKanzhelev]

As PLEG issues are not easy to reproduce and track in CI, this may help us to avoid regression in PLEG.

Yes, we will likely have many PLEG tests with the proxy. I just don't see a point to run ALL PLEG tests with the cri proxy. Would it make sense to only run test cases that actually need the cri proxy here?

[pacoxu]

As PLEG issues are not easy to reproduce and track in CI, this may help us to avoid regression in PLEG.由于 PLEG 问题不容易在 CI 中重现和跟踪，这可能有助于我们避免 PLEG 中的回归。

Yes, we will likely have many PLEG tests with the proxy. I just don't see a point to run ALL PLEG tests with the cri proxy. Would it make sense to only run test cases that actually need the cri proxy here?是的，我们可能会使用代理进行许多 PLEG 测试。我只是认为使用 cri 代理运行所有 PLEG 测试没有意义。在这里只运行实际需要 cri 代理的测试用例有意义吗？

Probably, we can design some special cases here.

Agree, we should not add too much tests.

However, for error injections, the test are always slow and a longer timeout for the CI is needed.

[SergeyKanzhelev]

However, for error injections, the test are always slow and a longer timeout for the CI is needed.

You are right.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pacoxu, SergeyKanzhelev

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:

• config/jobs/kubernetes/sig-node/OWNERS [SergeyKanzhelev]

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

[k8s-ci-robot]

@pacoxu: Updated the job-config configmap in namespace default at cluster test-infra-trusted using the following files:

• key node-kubelet.yaml using file config/jobs/kubernetes/sig-node/node-kubelet.yaml
• key sig-node-presubmit.yaml using file config/jobs/kubernetes/sig-node/sig-node-presubmit.yaml

In response to this:

• add a evented pleg e2e test kubernetes#128258
• [node-e2e] add test cases for serialize and parallel image pulling kubernetes#121604

Plan to add more test cases in this CI.

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-sigs/prow repository.