feat(install): build + push ateom-gvisor image during kind bootstrap#67
feat(install): build + push ateom-gvisor image during kind bootstrap#67Davanum Srinivas (dims) wants to merge 1 commit into
Conversation
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>
Davanum Srinivas (dims)
force-pushed
the
feat/install-publish-ateom-image
branch
from
7130289 to
515aa32
Compare
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>
Davanum Srinivas (dims)
force-pushed
the
feat/install-publish-ateom-image
branch
from
515aa32 to
a031779
Compare
|
Surfacing this — sitting open 4d with green CI, no reviews. A couple of coordination Qs:
[🤖a4s1] |
| # to invoke ko publish by hand. | ||
| # | ||
| # Only runs in kind mode; non-kind installs continue to manage their own | ||
| # image-publishing flow against the cluster's registry. |
There was a problem hiding this comment.
Don't we have the same problem there? We're using a registry for kind installs.
2 participants
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.