Self-review of the two commits above, three blockers.
The golden-deletion procedure was wrong for the case it was written for. It
told the operator to query live worker DataVolumes and read an empty result as
permission to delete. A pool sits at zero workers whenever the autoscaler has
nothing to place -- minReplicas: 0 is the default -- and it still pins its
golden, so that query answers "empty" for exactly the pool whose next scale-up
breaks. The pool declarations are the authority now, with the live disks as the
second read; both empty is the go-ahead.
Nothing asserted that the e2e suites take the clone path. Dropping the image
block from the KubernetesNodes heredoc, or landing it at the wrong indent, puts
the pool back on the HTTP import while every suite still passes -- the catalog
imports a golden nobody clones. That is the same silent-fallback shape this
branch already had to fix once, so it gets a guard, mutation-proven by deleting
the block and watching it fail.
The catalog suite covered only accepted input. Both `images[]` fields are
`required`, and what that refusal buys is the golden's name: an entry missing
either renders `talos-worker--<version>` or `talos-worker-<id>-`, and two such
entries collide on one DataVolume, so the second replaces the first and every
pool pinning it clones the wrong OS. Two cases now assert the refusal.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Myasnikov Daniil
6955a083c7