platform-package.md lists spec.components.platform.values.* key by key and nothing generates that page, so a new platform value only shows up there if someone adds it. Same shape as #688.
cozystack/cozystack#4171 adds kubernetesWorkerImage. Whatever is set under it is forwarded verbatim into the emitted cozystack.kubernetes-worker-image Package CR as components.kubernetes-worker-image.values, so it lands on that chart HelmRelease and deep-merges over its defaults.
| Value |
Default |
Description |
kubernetesWorkerImage |
{} |
Overrides for the optional worker image catalog. Empty forwards nothing and keeps the child chart defaults. |
kubernetesWorkerImage.imageFactoryURL |
"https://factory.talos.dev" |
Image Factory the golden images are imported from. An air-gapped or rate-limited cluster repoints this one import. |
kubernetesWorkerImage.storageClass |
"replicated" |
StorageClass the goldens are imported onto. CDI takes the storage layer clone path only when a worker pool and its golden share a class, so a cluster whose pools sit elsewhere has to move the goldens onto their class. |
kubernetesWorkerImage.storage |
"6Gi" |
Size of each golden DataVolume. A pool diskSize below this is refused at render, because a clone target cannot be smaller than its source. |
kubernetesWorkerImage.images |
one entry, schematic ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515 at v1.13.6 |
List of (schematicID, version) pairs to import. Each one becomes talos-worker-<schematicID>-<version> in cozy-public, which is what a pool names in osImage.builtin. |
Worth saying on the page that this key alone does not switch anything on. Package is opt-in, so cozystack.kubernetes-worker-image has to be in bundles.enabledPackages as well.
The two knobs that decide whether the feature works at all are imageFactoryURL and storageClass. Get the second one wrong and the pool render fails naming a fix the operator cannot apply from the pool side, because a golden class is fixed for its lifetime.
Entries are also not editable in place once their golden exists. A DataVolume spec cannot be patched, so changing storage, storageClass or the factory URL of an existing entry is rejected at render, and the supported move is a new (schematicID, version).
platform-package.mdlistsspec.components.platform.values.*key by key and nothing generates that page, so a new platform value only shows up there if someone adds it. Same shape as #688.cozystack/cozystack#4171 adds
kubernetesWorkerImage. Whatever is set under it is forwarded verbatim into the emittedcozystack.kubernetes-worker-imagePackage CR ascomponents.kubernetes-worker-image.values, so it lands on that chart HelmRelease and deep-merges over its defaults.kubernetesWorkerImage{}kubernetesWorkerImage.imageFactoryURL"https://factory.talos.dev"kubernetesWorkerImage.storageClass"replicated"kubernetesWorkerImage.storage"6Gi"diskSizebelow this is refused at render, because a clone target cannot be smaller than its source.kubernetesWorkerImage.imagesce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515atv1.13.6(schematicID, version)pairs to import. Each one becomestalos-worker-<schematicID>-<version>incozy-public, which is what a pool names inosImage.builtin.Worth saying on the page that this key alone does not switch anything on. Package is opt-in, so
cozystack.kubernetes-worker-imagehas to be inbundles.enabledPackagesas well.The two knobs that decide whether the feature works at all are
imageFactoryURLandstorageClass. Get the second one wrong and the pool render fails naming a fix the operator cannot apply from the pool side, because a golden class is fixed for its lifetime.Entries are also not editable in place once their golden exists. A DataVolume spec cannot be patched, so changing
storage,storageClassor the factory URL of an existing entry is rejected at render, and the supported move is a new(schematicID, version).