Skip to content

platform-test should assert the WorkerPool's workers are Running, not just the Substrate release pair #206

Description

@marians

Follow-up from the review of #199.

platform-test proves the Substrate halves are one release (proveSubstrateLine: the atelet image against every WorkerPool's spec.workerImage), which is an image-string comparison. A pool whose workers never schedule passes it: the images agree, the Helm releases are Ready, and nothing looks wrong.

That is the whole class #199 is about. The pool's pods are ate-controller's, not the Helm release's, so the install's kstatus wait never sees them. Today the only thing that reports it is skills-test burning its golden-boot timeout, and the message it prints is about the AgentTemplate, not about scheduling.

#199 adds a preflight that refuses an install whose rendered WorkerPool names an architecture no node carries, so the specific arm64 case is caught before it happens. But the preflight reads the render, not the cluster — anything else that keeps the workers Pending (a taint, a resource ceiling, a pin an overlay changed after the install) still passes every proof.

Suggested: a platform-test step asserting the WorkerPool's workers are Running and that the node they landed on carries the pool's spec.template.nodeSelector. Cheap — one pod list by ate.dev/worker-pool=kagent-default, one node read — and it turns a five-minute timeout in a later proof into a named failure in the one that is supposed to find it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions