mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-03 02:27:01 +09:00
Myasnikov Daniil
ea2ad97b9e
The three format guards run for every pool, including one with osImage omitted, so they apply to values a running cluster may already hold. The schema does not stop any of them: values.schema.json and the cozyrds openAPISchema type talos.version, talos.schematicID and talos.imageFactoryURL as bare strings with no pattern, so the CR accepts a malformed one and the pool's HelmRelease is what fails. Reproduced on a live stand rather than argued from the template. A KubernetesNodes carrying talos.version "v1.13" was admitted with the value intact and its HelmRelease went InstallFailed naming the format. Editing an unrelated field on that pool afterwards -- maxReplicas 1 to 3 -- was accepted by the CR and reached .spec.values of the HelmRelease, which stayed InstallFailed: the edit is taken everywhere and applied nowhere. That is the cost being documented, and it is why the shapes are named in prose where an operator reads them. Pattern is not expressible here. cozyvalues-gen writes types.go, values.schema.json, the README table and the cozyrd from values.yaml, and its annotation set has no pattern; a pattern added to values.schema.json by hand is erased by the next make generate, which is how this was checked. Teaching the generator that annotation is the follow-up that would let the rejection land on the CR instead. schematicID already documented its shape. version and imageFactoryURL now do too, the latter noting that a builtin pool builds no source URL and so is not held to it. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>