Repository navigation
Releases publish the envoy-dataplane image - #3252
Tim Hockin (thockin) merged 7 commits into
Conversation
The router and egress gateways run envoy-dataplane by default, so an install from a release could not use the default dataplane. The Dockerfile now cross-compiles the Rust module, so the release job builds it with buildx and no QEMU. Signed-off-by: Grant McCloskey <[email protected]>
releasedDockerfiles in images.go names the Dockerfile images a release publishes, so adding one is a one-line change like adding a ko image. The installer and the release build share images.EnvoyDataplane. Signed-off-by: Grant McCloskey <[email protected]>
PublishDockerfileImage read the digest back from the tag after pushing, so the release check that each tag names the pushed digest compared the tag with itself. It now reads containerimage.digest from the file --metadata-file writes. Also update comments and help text that still said releases leave out envoy-dataplane, or that only ko reads the ghcr.io login. Signed-off-by: Grant McCloskey <[email protected]>
bbd8614 to
404fbf6
Compare
With envoy-dataplane and the Kubernetes Secrets credential provider published, releases leave out only the demos and the benchmarking fakes, which an install deploys only when asked to. Signed-off-by: Grant McCloskey <[email protected]>
Steven Shriver (stshrive)
left a comment
There was a problem hiding this comment.
🤖 Agent-assisted adversarial review focused on CI failures and release-pipeline security. Severity: 🔴 Blocker, 🟡 Should Fix, 🟢 Nit. Checked without findings: merges cleanly onto main, the setup-buildx-action SHA matches the existing pin in pr-workflow, the Dockerfile base images are digest-pinned, CheckPublished ignores buildx attestation entries, and package visibility is already covered in docs/dev/releasing.md.
The images job builds envoy-dataplane with the ghcr.io login, so its BuildKit image is now pinned by digest, and the dry run uses the same one. Release builds ignore DOCKER_BUILD_FLAGS, so they restore no cache, and build the Dockerfile images before the ko images, so a failed envoy build publishes nothing under the tag. The error for a missing envoy-dataplane again suggests --atenet-dataplane=agentgateway, since older releases, mirrors, and a package that is still private have no readable copy. Signed-off-by: Grant McCloskey <[email protected]>
Steven Shriver (stshrive)
left a comment
There was a problem hiding this comment.
🤖 Agent-assisted functional review: can a user install a release on a cluster and run a demo? With envoy-dataplane published, every image a default install deploys is either a release image or a public, digest-pinned third-party image, so ate-setup deploy ate-system --image-repo ghcr.io/agent-substrate/substrate --image-tag <tag> from a checkout at the tag should work, --kind included.
🟡 Should Fix: cmd/ate-setup/README.md:29-31, under "Installing pre-built images", still says: "The images a release publishes to ghcr.io/agent-substrate/substrate are not enough on their own". This PR updated the matching text in commands.md, releasing.md, substrate-install.yaml and draft-release.sh, but this file isn't in the diff, and it is the main doc for pre-built installs. It should say what commands.md:85-88 now says.
| Both lists are allowlists in `images.go`: `released` for the ko images and `releasedDockerfiles` for the images built from a Dockerfile. A new image is not published until a pull request adds it there, so publishing an image is always an explicit, reviewed change. | ||
|
|
||
| It leaves out `envoy-dataplane`, the demos, and the benchmarking fakes. The release images are therefore not a complete install of the default configuration, and the notes give no install command: an install has to take the images releases leave out from another registry, or build them from source. `ate-setup --image-repo` looks those images up like any other; if one is missing, the error says releases do not publish it. | ||
| It leaves out the demos and the benchmarking fakes, which an install deploys only when asked to. An install that needs them has to take them from another registry, or build them from source. `ate-setup --image-repo` looks those images up like any other; if one is missing, the error says releases do not publish it. |
There was a problem hiding this comment.
🤖 🟡 Should Fix: "An install that needs them has to take them from another registry, or build them from source" doesn't tell a user who installed a release how to run a demo. Six of the seven demos need an image releases don't publish, and the error they hit (prebuilt.go:136) says to publish it to ghcr.io/agent-substrate/substrate themselves, which they can't, or to drop --image-repo, without saying the system install can keep it. The tool already supports the mixed flow: deploy demo resolves only the demo's WorkerPool and ActorTemplates, so the control plane can come from the release while the demo is built from source. Please document it next to the release-install command, e.g.:
hack/create-kind-cluster.sh
go run ./cmd/ate-setup deploy ate-system --kind --credential-provider='{"name":"k8s.io"}' \
--image-repo ghcr.io/agent-substrate/substrate --image-tag vX.Y.Z
# Demo images are not released; build them from this checkout (at vX.Y.Z) into the kind registry.
go run ./cmd/ate-setup deploy demo demo-counter --kind
Also say that jupyter needs no build, that the demo step needs Go, ko and docker and must not inherit images.repo or ATE_IMAGE_REPO, and that outside kind it needs KO_DOCKER_REPO set to a registry the cluster can pull from. Updating the prebuilt.go:136 hint to point at this would close the loop. Fine as a follow-up under #3217 if you'd rather keep this PR focused.
There was a problem hiding this comment.
I would like to do the release-plus-demo flow and the prebuilt.go hint as a follow-up under #3217, so this PR stays on publishing envoy-dataplane.
|
Steven Shriver (@stshrive) thanks for review, coving the comments, some things I defered because I wasn't sure they were needed but no harm in covering it all now. I will do a mock release in my own repo to validate the workflow |
envoyproxy/envoy sets org.opencontainers.image.version to its Ubuntu release, which envoy-dataplane inherited. Every release image now carries the release tag in that label. Also fix the ate-setup README, which still said release images are not enough for an install. Signed-off-by: Grant McCloskey <[email protected]>
With every image a default install deploys now published, the notes show how to install a release from a checkout of its tag. The pre-built install examples in the ate-setup docs now pass --ingress-allowed-spiffe-ids, which the envoy router requires, and say that running ate-setup still needs Go. Signed-off-by: Grant McCloskey <[email protected]>
|
Steven Shriver (@stshrive) the README text from your functional review ("not enough on their own") is fixed in 619f0d9. |
|
Tim Hockin (@thockin) This should be in a valid state right now. I ran a mock release off my fork with fake tags. |
Part of #3217. The default atenet dataplane runs envoy-dataplane in the router and egress gateways, but releases do not publish it, so a pre-built install has to use
--atenet-dataplane=agentgatewayor build from source. #2112 dropped it because building Rust under QEMU was slow. #3152 made the Dockerfile cross-compile, so the release job now builds it with buildx and no QEMU.Released Dockerfile images are an allowlist (
releasedDockerfiles) next to the ko allowlist. The release jobs pin BuildKit by digest. Release builds take each Dockerfile image's digest from buildx's--metadata-file, build Dockerfile images before the ko images, ignoreDOCKER_BUILD_FLAGS, and label every image with its source, revision and version. With every image a default install deploys now published, the release notes give the install command.After the first release that includes it, an org owner has to make the new
ghcr.io/agent-substrate/substrate/envoy-dataplanepackage public.Validation
release.yamlfrom this branch, run in my fork at 619f0d9 with a throwaway tagv0.0.0-envoytest.1:images-dry-run, dispatched withdry_run_images, built all eleven release images cold onubuntu-latestand passed the platform and digest checks in 11m35s, well inside the 30-minute timeout.Earlier, at bbd8614, I ran the same publish locally against a throwaway registry, as the
images-dry-runjob does:linux/amd64->arm64), with no QEMU.--metadata-filematched what the tag resolved to.linux/amd64andlinux/arm64, and thesourceandrevisionlabels.That run showed envoy-dataplane inheriting
org.opencontainers.image.version: "22.04"from the Ubuntu base ofenvoyproxy/envoy. Release images now set that label to the release tag.AI use: I used Claude Code to trace the code #2112 removed, draft the change, address review comments, and script the local and fork validation. I reviewed the diff and ran the ate-setup tests and the validation above.