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.

Hi @p-shah256. 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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: p-shah256
Once this PR has been reviewed and has the lgtm label, please assign klueska for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

testing to see if any SeparateDisk tests run on non relevant CI jobs

/test pull-crio-cgroupv1-node-e2e-features

@p-shah256: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

/ok-to-test

There is not yet a way to skip these feature jobs by default and many lanes pick up the “Feature:” label so you will want to say this job is skipped.

There is a solution: change you jobs to use --label-filter=feature: isSubsetOf { FeatureA, FeatureB, ... } for all features supported by the job setup. That's an allow list.

As long as you use explicitly skips instead, you are stuck with updating those deny lists each time you add a new feature.

There is not yet a way to skip these feature jobs by default and many lanes pick up the “Feature:” label so you will want to say this job is skipped.

There is a solution: change you jobs to use --label-filter=feature: isSubsetOf { FeatureA, FeatureB, ... } for all features supported by the job setup. That's an allow list.

As long as you use explicitly skips instead, you are stuck with updating those deny lists each time you add a new feature.

Yes, the solution is that but that is tricky to pull off for every existing job in sig-node.

Most people are just copying existing jobs. I've tried my best to block kubernetes_e2e.py and encourage copying kubetest2 from getting in but nothing gates people from adding "deprecated" jobs.

but nothing gates people from adding "deprecated" jobs

Reduce ownership to a handful of people who know where the SIG wants to go with its jobs? Then also add a README outlining what a job should look like and start converting the existing ones. Eventually you will only have "good" examples and approval can be opened up again.

#130964 (review)

/lgtm

/assign @mrunalp @SergeyKanzhelev @ffromani

We still need to exclude jobs from the CI in test-infra but this can help reduce the amount we need to exclude.

/hold

I think maybe we just revert the other PR. The failures are pretty vast and its risky to leave these in.

@kannon92 yes please add a revert for the other PR!

#130985 is open.

PR needs rebase.

Given the two proposed solutions (@pohly allowlist approach with --label-filter vs adding explicit skips to failing jobs), I'm looking for clear direction.
While the allowlist approach seems more architecturally sound, I recognize there may be practical constraints with existing jobs. I'm ready to execute on whichever approach the team prefers for moving forward.

1. I'd modify the CI jobs to make sure it ignores new Feature flags
2. revert the reverted PR once that's set up

@p-shah256 can you resubmit your tests as a PR?

/lgtm cancel

To clear it up from queries