feat(install): build + push ateom-gvisor image during kind bootstrap#67
Open
Davanum Srinivas (dims) wants to merge 1 commit into
Open
feat(install): build + push ateom-gvisor image during kind bootstrap#67Davanum Srinivas (dims) wants to merge 1 commit into
Davanum Srinivas (dims) wants to merge 1 commit into
Conversation
Davanum Srinivas (dims)
added a commit
to dims/openshell-driver-substrate
that referenced
this pull request
May 23, 2026
Now that the three companion changes are filed upstream as - NVIDIA/OpenShell#1548 (env-var-gated best-effort bootstrap) - agent-substrate/substrate#66 (ateom-gvisor eth0 fix) - agent-substrate/substrate#67 (install-ate.sh publishes ateom-gvisor) rewrite the README + poc-intro.md to point at the PRs rather than at specific commits or fork branches. Easier to follow for any reader who isn't already deep in our local-fork state. Also fold the operator-handshake follow-up into the §3 component table and §9 "Where to next" list with the PR reference. Signed-off-by: Davanum Srinivas <davanum@gmail.com>
ateom-gvisor is the per-worker-pod sidecar referenced via WorkerPool.spec.ateomImage. Its source lives under cmd/ateom-gvisor but it has no Deployment/DaemonSet manifest in manifests/ate-install/, so the ko-resolve pipeline that builds every other binary never builds it. Operators creating a WorkerPool after a fresh --deploy-ate-system have to either run a packaged demo (its template's ko:// reference side-effects the build) or invoke ko publish by hand. Add publish_ateom_image() that runs ko publish --base-import-paths ./cmd/ateom-gvisor and writes the resulting <repo>@sha256:<digest> to .ate-kind/ateom-image. Invoke it from the end of deploy_ate_system when ATE_INSTALL_KIND=true, and expose --publish-ateom-image so the image can be rebuilt alone after a code change. .ate-kind/ is gitignored. Non-kind installs are unaffected — operators retain control of their own image-publishing flow against the cluster's registry. Signed-off-by: Davanum Srinivas <davanum@gmail.com>
7130289 to
515aa32
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ateom-gvisoris the per-worker-pod sidecar referenced viaWorkerPool.spec.ateomImage.Its source lives under
cmd/ateom-gvisor, but noDeploymentorDaemonSetmanifest undermanifests/ate-install/references it. Theko resolvepipeline that builds every other binary therefore never buildsateom-gvisor.After a fresh
hack/install-ate-kind.sh --deploy-ate-system, operators creating aWorkerPoolhave to either:ko://reference side-effects the build), orko publish ./cmd/ateom-gvisorby hand and substitute the resulting digest into their manifest.Add
publish_ateom_imagetohack/install-ate.sh. It runs:and writes the resulting
<repo>@sha256:<digest>to.ate-kind/ateom-image.Wiring:
deploy_ate_systemwhenATE_INSTALL_KIND=true.--publish-ateom-imagefor standalone rebuilds..ate-kind/added to.gitignore.