cc @mbobrovskyi @dgrove-oss @yaroslava-serdiuk @tenzen-y

Actually, I think with #3804 it should be relatively simple to start a new e2e suite within the same CI job with that configuration. So, I would suggest starting with that. The Pod-based integration is easier to test e2e than integration, because pods are actually created by kube-controller-manager's controllers (Deployment or StatefulSets). cc @dgrove-oss @tenzen-y @mbobrovskyi .

We could start with the e2e tests for the "sanity" checking and add more integration tests for corner cases.

/assign

/unassign

Sorry, I don't have capacity to work on it for now.

/assign

I'll take this one since is a requirement to tackle #3829

/reopen
For the follow ups: #4112 (review)

@mimowo: Reopened this issue.

I think with the ground work of #4112 we are ready to add some tests coverage which is crucial for correctness of this configuration with the pod-based frameworks.

I'm thinking about covering the following scenarios:

1. create Pod/Deployment/StatefulSet without queue-name in test namespace and verify it is suspended, then delete the API objects and verify the child pods are removed too
2. create a Pod/Deployment/StatefulSet without queue-name in kube-system and verify they run, then delete the API objects and verify the child pods are removed too

I believe there are numerous nuances between the integrations which are very hard to test with integration test because they rely on pod creation and integration with kube-controller-manager (especially for StatefulSet).

The scenarios above will require enabling the integrations in the Kueue configuration. IIUC we could just add more "Its" for them here.

My preference is to split the work into small PRs so that we can react and change plans as we continue the work.

cc @dgrove-oss @tenzen-y