e2e-framework: Consistent use of configurable timeouts

[johnSchnake]

What would you like to be added?

Cleanup work to remove more of the deprecated timeouts, especially throughout the conformance tests. There are newer, configurable timeouts that are available via the framework.Timeouts object.

Some of the deprecated framework timeouts constants are still used: https://github.com/kubernetes/kubernetes/blob/master/test/e2e/framework/util.go#L87-L154

For instance, even on the quick mode test Sonobuoy runs, it uses the deprecated timeout which cant be configured (and another timeout just hardcoded below that): https://github.com/kubernetes/kubernetes/blob/master/test/e2e/common/node/pods.go#L292-L295

Why is this needed?

When running tests in certain environments you can know whether or not certain types of operations are likely to run quickly/slowly. Most of the tests and their timeouts are made with very general assumptions so that they apply to all tests, but in certain use cases they are not adequate.

Personally, in my use case, I am trying to run lots of short tests (short on the happy path) but due to un-editable timeouts, the failures take numerous minutes.

Updating every reference to the deprecated values may take time, but some of them should be straight forward.

/kind cleanup
/area e2e-test-framework
/sig testing

[k8s-ci-robot]

@johnSchnake: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[johnSchnake]

/remove-kind feature

[aojea]

/cc

[NikhilSharmaWe]

@aojea and @johnSchnake I would like to work on it.

Could you please give me some idea or steps should be taken on how can I prevent the source code from using deprecated timeout constants.

• @johnSchnake mentioned that Updating every reference to the deprecated values may take time, but some of them should be straight forward. How can we know that where these constants are used in the repo and what should be used in place of them.

I am not very sure that these are right questions to ask.

[johnSchnake]

@NikhilSharmaWe I linked to the constants that are commented as being deprecated and showed an example.

The way the timeouts should be referenced are via f.Timeouts.<specificTimeout>. This .Timeouts struct can be configured, the deprecated constants can't be.

The unknown is in which cases they can easily be swapped (do you have access to the framework object?) or if you need to pass the method a framework object (which will cause the changes to multiply since you have to pass the framework object through potentially numerous calls. I'm hoping we have more of the easy cases where you can just update the value used.

As for finding them, simply search through the codebase, nothing fancy needed.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[oomichi]

@JohnTitor is active for this issue now.

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.