mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-11-08 12:26:36 +00:00
Joseph Antony VaikathandClaude Code
ff42d943d6
* fix(tilt): make the dev setup work on a clean checkout and on arm64
Following tilt.md from a clean checkout failed during Tiltfile load:
Error in default_registry: validating defaultRegistry: host: Required value
The docs correctly say to leave default_registry empty for a local cluster,
where Tilt loads the image into the cluster and nothing is pushed, but
default_registry("") is rejected. Only call it when a value is set. For the
build, hack/build.sh also refuses an empty REGISTRY; that value is only the
image prefix baked into the binary, so fall back to the stock one.
Working past that, both binary builds failed with "GOBIN: unbound variable",
which hack/build.sh has required since b1d95cf2a. Pass it.
Everything was also hardcoded to amd64 -- the three binary builds, the
downloaded kubectl helper, the runtime base image, and both docker_build
calls -- so the setup was broken on an arm64 host. Resolve cluster_goarch
once, from an explicit setting, then what `kubectl get nodes` reports, then
the local architecture, and use it throughout. The local CLI build follows
the host instead, since it is meant to be run there.
The provider path deliberately does not get GOBIN: released plugins ship
their own hack/build.sh, which builds ${PKG}/${BIN} and does not require it.
Only its amd64 assumptions change here.
Finally, pin the Delve version. @latest meant the debugger could change
between rebuilds with no change to the checkout.
Verified: Tiltfile loads with an empty and a non-empty registry, with debug
on and off, continue-on-start on and off, and with an explicit
cluster_goarch override; the generated Dockerfiles carry the right arch,
dlv pin, kubectl and docker CLI URLs; the provider path was exercised
against velero-plugin-for-aws; and hack/build.sh produced an aarch64 binary
when GOARCH=arm64.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* docs(tilt): correct the settings reference and the examples
The settings example is not valid JSON: a trailing comma follows the azure
entry, so copying it gives a parse error on the next `tilt up`.
It also enables "csi" in enable_providers while giving it no entry under
providers, so the example advertises a provider it does not define.
provider_repos is documented as a settings field but nothing reads it; the
list of plugins to load is providers. Replace it with cluster_goarch, which
the Tiltfile does read, and say what an empty default_registry means, since
leaving it empty is what a local cluster wants.
The Tilt version floor moves to v0.30.0, the first with
docker_build(platform=...), without which the arm64 support does not load.
Drop the Kubernetes v1.16 floor, which no longer means anything here.
The example deployment gets 3Gi when debugging. delve indexes the DWARF of
the unoptimized binary, and against a 512Mi limit the container is killed
before the debugger finishes starting.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* changelog: add an entry for the Tilt dev setup fixes
The filename is keyed to the PR number, which only exists once the PR does.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* fix(tilt): use pullable MinIO images in the dev setup example
The example tilt-settings.json ships "setup-minio": true, and tilt.md tells
contributors that this creates "a running instance of MinIO inside your
cluster", after which they can "create backups/restores and fully operate
Velero". That is no longer reachable: minio/minio:latest and minio/mc:latest
are no longer pullable from Docker Hub, so the MinIO deployment and its setup
Job both sit in ImagePullBackOff and no backup storage location can validate.
$ docker pull minio/minio:latest
Error response from daemon: {"message":"denied: requested access to the
resource is denied"}
The kind e2e workflow already stopped using these images and builds MinIO from
a reviewed bitnami/containers commit instead. Follow the same namespace here
rather than building from source, since this example runs on a contributor's
laptop: the bitnami legacy mirrors are pullable and need no Dockerfile.
bitnami splits the server and client into separate images, so the setup Job's
minio/mc must move to bitnamilegacy/minio-client, which provides mc on PATH.
Verified both images pull, run as non-root against the emptyDir mounts, and
that the Job completes ("Bucket created successfully `velero/velero`"). With
these images the backup storage location reports Available and a backup
completes and lands in the bucket.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* fix(tilt): extract kubectl where the Dockerfile copies it from
The helper stage unpacks the kubectl tarball without -C, so it lands in the
golang image's WORKDIR (/go) rather than /tmp, but the COPY that follows reads
from /tmp. The build fails with:
checking on sources under ".../tmp/kubernetes/client/bin/kubectl"
Unpack to /tmp, matching the docker CLI download on the next line and the
COPY --from path.
While here, note next to the dlv pin that it has to move with the golang
image: delve refuses a binary built by a newer Go than it understands
("Version of Delve is too old for Go version go1.x.y"), so the pin goes stale
quietly on the next Go bump.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* fix(tilt): glob the CRDs instead of listing them
The hardcoded list has to be edited whenever a branch adds a CRD, and silently
drops it from the cluster until someone notices. Glob config/crd/*/bases/*.yaml
instead; it resolves to the same 13 files today.
The glob is a local() call, and Tilt refuses local() while the current kube
context might be a production one, so the k8s_yaml() sits after
allow_k8s_contexts() rather than at the top of the file with the other
manifests.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
---------
Signed-off-by: Joseph <jvaikath@redhat.com>
Signed-off-by: Joseph Antony Vaikath <jvaikath@redhat.com>
Co-authored-by: Claude Code <noreply@anthropic.com>