From 2b3c163d152ff0eaa65af003f35e761b8f0e8cc3 Mon Sep 17 00:00:00 2001
From: Aleksei Sviridkin <3811295@gmail.com>
Date: Sat, 15 Aug 2026 18:34:13 +0300
Subject: [PATCH] fix(e2e): size tenant workers by resources, not by u1.large

Sizing the workers with u1.large doubled their memory along with the
vCPUs, and four 8Gi workers do not fit on the sandbox beside the rest of
the suite: the second worker of each cluster stayed Pending with
Insufficient memory on all three nodes, so the node group could never
reach two Ready nodes and node-join failed for a reason that has nothing
to do with the CPU ceiling it was meant to test.

Setting resources.cpu and resources.memory keeps the two vCPUs at the
memory the workers had before. The chart drops the instancetype from the
VM when a group sets both, and the values schema still requires the
field, so it stays in the values as the sizing fallback it now is.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <3811295@gmail.com>
---
 hack/e2e-chainsaw/_lib/run-kubernetes.sh | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/hack/e2e-chainsaw/_lib/run-kubernetes.sh b/hack/e2e-chainsaw/_lib/run-kubernetes.sh
index 9318e340f..89889e9c1 100644
--- a/hack/e2e-chainsaw/_lib/run-kubernetes.sh
+++ b/hack/e2e-chainsaw/_lib/run-kubernetes.sh
@@ -2651,7 +2651,10 @@ ${ouroboros_addon}
     md0:
       diskSize: 20Gi
       gpus: []
-      instanceType: u1.large
+      # Sizing comes from resources below; this is here because the values
+      # schema requires the field, and the chart drops the instancetype from
+      # the VM whenever a group sets both resources.cpu and resources.memory.
+      instanceType: u1.medium
       # The failure this suite keeps hitting is a worker that stalls in the
       # guest before Talos apid answers, which leaves nothing to read on the
       # management side and nothing for talosctl to connect to. Turning this on
@@ -2660,7 +2663,14 @@ ${ouroboros_addon}
       logSerialConsole: true
       maxReplicas: 10
       minReplicas: 2
-      resources: {}
+      # Two vCPUs at the memory the workers had before. Sized by resources
+      # rather than by instanceType: u1.large doubles memory along with the
+      # vCPUs, and four 8Gi workers do not fit beside the rest of the suite,
+      # so the second worker of each cluster stayed Pending on Insufficient
+      # memory and the node group never reached two Ready nodes.
+      resources:
+        cpu: 2
+        memory: 4Gi
       roles:
       - ingress-nginx
   storageClass: replicated