TAS: introduce sanity e2e test

[mimowo]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

To make sure TAS works e2e, including computing the assignment and ungatibg the pods.

Which issue(s) this PR fixes:

Part of #2724

Special notes for your reviewer:

I'm happy to add more scenarios in this PR or on follow ups.

Does this PR introduce a user-facing change?

NONE

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue canceled.

Name	Link
🔨 Latest commit	c859074
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kueue/deploys/671a087f5ebfdb0008ca605f

[mimowo]

/cc @gabesaba @PBundyra @tenzen-y

[mimowo]

/test pull-kueue-test-multikueue-e2e-main
again: go: sigs.k8s.io/[email protected]: sigs.k8s.io/[email protected]: Get "https://proxy.golang.org/sigs.k8s.io/kind/@v/v0.24.0.zip": dial tcp 142.250.191.241:443: connect: no route to host

[tenzen-y]

I will pass the first review to @gabesaba

[PBundyra]

Where does this value come from?

[mimowo]

From the cluster yamls config https://github.com/mimowo/kueue/blob/main/hack%2Fkind-cluster.yaml#L19 specifies names of the worker nodes. I think the prefix 'kind-' is added by default, might be the cluster name

[mimowo]

I check experimentally that the prefix comes from the cluster name, so I created a new kind cluster mycluster, and the nodes are named: mycluster-worker, mycluster-worker2. So the index must also be added by kind.

[gabesaba]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 79e94b1ea3547e8990cfc4ff6f774fcd0d149d69

[tenzen-y]

/hold

[mimowo]

I consider this a sanity test to verify basic scenarios. Most importantly to test that the assignment is set and the topology ungater lets the Pods to start and complete. Maybe also we could extend it in the future to cover some cases in #3292.

However, ultimately I think for Beta it would be have a dedicated CI Job just for TAS where we can setup a more complex node structure. Similarly as we have a dedicated CI job for multikueue: pull-kueue-test-multikueue-e2e-main. WDYT @tenzen-y @PBundyra ?

[tenzen-y]

I consider this a sanity test to verify basic scenarios. Most importantly to test that the assignment is set and the topology ungater lets the Pods to start and complete. Maybe also we could extend it in the future to cover some cases in #3292.

However, ultimately I think for Beta it would be have a dedicated CI Job just for TAS where we can setup a more complex node structure. Similarly as we have a dedicated CI job for multikueue: pull-kueue-test-multikueue-e2e-main. WDYT @tenzen-y @PBundyra ?

That makes sense. We will set up multiple Nodes with different node labels to simulate TAS situations, right?

[mimowo]

That makes sense. We will set up multiple Nodes with different node labels to simulate TAS situations, right?

Yes, we can figure out details later, but I think we could have, for example, 8 nodes divided into 2 blocks and 4 racks.

EDIT: added the point to the spreadsheet. I will also update the KEP after alpha.

[tenzen-y]

That makes sense. We will set up multiple Nodes with different node labels to simulate TAS situations, right?

Yes, we can figure out details later, but I think we could have, for example, 8 nodes divided into 2 blocks and 4 racks.

EDIT: added the point to the spreadsheet. I will also update the KEP after alpha.

That sounds great.

[tenzen-y]

Basically, lgtm

[tenzen-y]

Thank you!
/lgtm
/approve
/hold cancel

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 0f7aaf1831d85adb6bcbe041ad8239789c0b361b

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mimowo, tenzen-y

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:

• test/OWNERS [mimowo,tenzen-y]

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