Benjamin Elder
e9286451a7
stage-to-rustfs.sh required developers to install the `aws` CLI, and reached rustfs through a `kubectl port-forward`. The port-forward is a footgun: when it targets the wrong cluster, or runs before the control plane exists, the uploads fail against a dead localhost:9000 rather than saying rustfs isn't there. Run the S3 client in a throwaway container instead, using the same pinned amazon/aws-cli image as the rustfs-bucket-init Job that creates the bucket, and stream each asset in on stdin. The container joins the kind node's network namespace so rustfs's ClusterIP is routable -- a container merely attached to the `kind` docker network reaches the node's own IP but has no route to the service or pod CIDRs. Dropping the port-forward also fixes the macOS case, where a container cannot reach it at all (the container's localhost is the Docker VM, not the host). Also wait for the rustfs rollout and the bucket-init Job before uploading, so running this too early reports what it's waiting on instead of timing out on a connection. Fixes #<issue_number_goes_here> > It's a good idea to open an issue first for discussion. - [x] Tests pass - [x] Appropriate changes to documentation are included in the PR Surfaced in https://github.com/agent-substrate/substrate/pull/743
Micro-VM runtime assets + counter demo (kind, fetch-not-bake)
The microvm runtime (cmd/ateom-microvm, kata + cloud-hypervisor) fetches its
toolchain at runtime — nothing kata-specific is baked into the worker image. ateom drives
the kata-agent directly (no kata shim, no containerd). Each actor container's rootfs is an
overlay of a read-only lower (the OCI image, served into the guest over virtio-fs by
virtiofsd) and a writable upper on a guest tmpfs, so virtiofsd is part of the asset
set. The asset set is five files:
cloud-hypervisor— the VMM binary (fetched from its release)virtiofsd— the virtio-fs daemon serving the RO lower (built from source; seeassemble.sh)vmlinux— the guest kernel (from kata-static)rootfs.img— the guest rootfs image (from kata-static)configuration-clh.toml— the base kata config (from kata-static)
These helpers assemble the asset set for your node arch, stage it into the cluster's rustfs
S3 bucket, and the demo manifest's SandboxConfig points at it. When /dev/kvm is
available, hack/create-kind-cluster.sh mounts it into the node and labels the node
ate.dev/sandboxClass=microvm.
Tip
hack/run-microvm-demo.shautomates the full bring-up below (assets, control plane, demo apply) for kind OR GKE without editing committed files. The steps here are the manual equivalent.
Steps (run on a KVM-capable Linux host matching the node arch)
-
Assemble assets for your arch:
ARCH=arm64 hack/microvm-assets/assemble.shCopy the printed sha256 sums into the
SandboxConfigspec.assetsindemos/counter/counter-microvm.yaml.tmpl(the committed values are arm64; other arches differ). -
Bring up the cluster + control plane:
hack/create-kind-cluster.sh # mounts /dev/kvm, labels node ate.dev/sandboxClass=microvm hack/install-ate-kind.sh # control plane + rustfs (bucket: ate-snapshots) -
Stage assets into rustfs:
OUT="$PWD/microvm-assets-arm64" hack/microvm-assets/stage-to-rustfs.sh -
Apply the demo + drive it:
BUCKET_NAME=ate-snapshots envsubst < demos/counter/counter-microvm.yaml.tmpl | kubectl apply -f -Create an actor from
counter-microvm, hit the in-RAM counter to increment it, suspend (checkpoint), resume on a different worker pod, and confirm the count continues — proving the guest-memory snapshot round-tripped across pods.
Notes
assetsis single-arch (unlike runsc's amd64/arm64): stage assets matching the node arch.