Skip to content

Ship a reference cell image instead of telling everyone to bake one - #9

Merged
wrkode merged 1 commit into
mainfrom
docs/reference-cell-image
Aug 9, 2026
Merged

Ship a reference cell image instead of telling everyone to bake one#9
wrkode merged 1 commit into
mainfrom
docs/reference-cell-image

Conversation

@wrkode

@wrkode wrkode commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

The quickstart's largest prerequisite was "build a cell image" — about an hour of baking a 30 GiB disk — while the image this project's own hardware validation ran on was already published and, since the packages went public, pullable by anyone. Nothing pointed at it.

config/samples/swiftimage-cell.yaml now does, so the prerequisite becomes:

kubectl apply -f config/samples/swiftimage-cell.yaml

Verified before documenting, not after

  • Anonymous pull (no credentials) returns HTTP 200, artifactType: application/vnd.kubeswift.vmimage.v1, 11 GiB across 44 layers.
  • The SwiftImage reaches Ready on a cluster with no pull secret in the namespaceImporting → Validating → Ready in ~7 minutes, prepared as a 30Gi raw artifact.

That last check mattered: every earlier import in this project used a credentialsSecretRef, and the first step of the quickstart now depends on that no longer being necessary. Had it failed, the claim would have come straight back out.

Labelled for what it is

Two things pin the image, and either can make it the wrong choice:

driver 580.173.02, proprietary branch chosen for a Pascal card (GTX 1080); the open kernel modules are Turing and newer only
node binaries are k0s a kubeadm/RKE2/k3s user gets the driver and container toolkit but not their node binaries — install them from the join cloud-init, or bake for their distribution

docs/cell-image.md now leads with using the published image and keeps the build path for when it is the wrong one.

Also

docs/limitations.md links each tracked gap to its issue (#2 rolling update, #3 outer-drain sequencing, #4 HAMi DRA mode, #5 multi-cell hardware validation), so a reader can tell whether something is being worked on rather than only that it is missing.

🤖 Generated with Claude Code

… one

The quickstart's largest prerequisite was "build a cell image" — roughly an hour of
baking a 30 GiB disk — while the image this project's own hardware validation ran on was
sitting published and, since the packages were made public, pullable by anyone. Nothing
pointed at it.

config/samples/swiftimage-cell.yaml now does. Verified before documenting rather than
after: anonymous pull returns 200 with artifactType application/vnd.kubeswift.vmimage.v1
(11 GiB, 44 layers), and the SwiftImage reaches Ready on a cluster with NO pull secret in
the namespace — which mattered, because every earlier import in this project used one and
the very first step of the quickstart now depends on that no longer being true.

Labelled for what it is, not oversold: driver 580.173.02 from the PROPRIETARY branch
because it was chosen for a Pascal card, and k0s node binaries. A kubeadm, RKE2 or k3s
user gets the driver and container toolkit they need but not their node binaries, so they
install those from the join cloud-init or bake for their distribution. docs/cell-image.md
now leads with using the published image and keeps the build path for when it is the wrong
image.

Also links each tracked gap in docs/limitations.md to its issue (#2 rolling update, #3
outer-drain sequencing, #4 HAMi DRA mode, #5 multi-cell hardware validation), so a reader
can see whether something is being worked on instead of only being told it is missing.

Signed-off-by: William Rizzo <william.rizzo@gmail.com>
@wrkode
wrkode merged commit 2186ed9 into main Aug 9, 2026
4 checks passed
@wrkode
wrkode deleted the docs/reference-cell-image branch August 9, 2026 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant