Skip to content

hack: stage micro-VM assets without a host aws CLI or port-forward - #804

Open
Benjamin Elder (BenTheElder) wants to merge 1 commit into
agent-substrate:mainfrom
BenTheElder:microvm-stage-assets-no-host-aws
Open

hack: stage micro-VM assets without a host aws CLI or port-forward#804
Benjamin Elder (BenTheElder) wants to merge 1 commit into
agent-substrate:mainfrom
BenTheElder:microvm-stage-assets-no-host-aws

Conversation

@BenTheElder

Copy link
Copy Markdown
Collaborator

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.

  • Tests pass
  • Appropriate changes to documentation are included in the PR

Surfaced in #743

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.
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