mirror of
https://github.com/hanzoai/s3-csi.git
synced 2026-09-30 23:52:32 +00:00
e8b89e78c3
* fix(docker): clone the fork that exists, at a commit that exists
The s3-mount image has never built. A global rename turned the upstream
seaweedfs reference into `github.com/s3/s3`, which is not a repository, so the
build died on `git clone ... exit code 128` before compiling anything.
Three more things were wrong behind it, each of which would have failed the next
step in turn:
clone github.com/s3/s3 -> github.com/hanzoai/s3
path /go/src/github.com/s3/s3 -> /go/src/github.com/hanzoai/s3
dir cd weed -> cd s3 (the fork renamed it)
commit 19ce7c0b6fdb -> 6dda4e4d6bca
That commit is the real one. 19ce7c0b6fdb is an UPSTREAM seaweedfs hash and does
not exist in our fork — the API 422s on it — so the checkout could never have
succeeded even with the URL fixed. The ARG stays so a build can still pin.
SEAWEEDFS_COMMIT is renamed S3_COMMIT while we are here; nothing consumed it yet.
* chore: no seaweed, no weed — it is s3
369 occurrences across 33 files, plus nine files whose names carried it. All of
it gone: manifests, helm chart, nomad jobs, workflows, docs and code.
Two of these were not cosmetic.
The driver spawned a binary called "weed":
DefaultWeedBinary = "weed"
Our fork builds it as `s3` — the running filer pod has /usr/bin/s3 and no weed
at all — so every mount would have failed with an executable that is not there,
however well the image built.
And the crash-recovery integration test killed processes matching `pgrep -x
weed`. Nothing is named that any more, so it would have found no pids, killed
nothing, and passed while testing exactly nothing. It now matches `s3`. The test
already had a guard that fails when there is nothing to kill, which is the only
reason this would have been noticed at all.
The rest follows the same rename the Dockerfile got: SEAWEEDFS_COMMIT is
S3_COMMIT, and the release/sync workflows that patch that ARG were updated with
it or they would silently stop pinning anything.
No upstream import paths were touched — go.mod depends on github.com/hanzoai/s3,
not on anything upstream, so nothing here was load-bearing for the build.
Verified: go build clean, all three test packages pass.
---------
Co-authored-by: hanzo-dev <[email protected]>
Co-authored-by: Hanzo Dev <[email protected]>
41 lines
1.8 KiB
HCL
41 lines
1.8 KiB
HCL
# id - Nomad internal ID. It is not sent to the CSI plugin but is used by Nomad for `per_alloc`
|
|
# volume configurations, etc.
|
|
id = "example-s3-volume"
|
|
# name - the name sent to the CSI plugin as an idempotency key and suggested volume ID. The CSI
|
|
# spec requires the calling Container Orchestrator to respect the actual volumeId returned by the
|
|
# CSI plugin. Nomad does this, storing it as the volume's ExternalID and using it in subsequent
|
|
# calls to the controller and node.
|
|
name = "example-s3-volume"
|
|
type = "csi"
|
|
plugin_id = "s3"
|
|
|
|
capacity_min = "256GiB"
|
|
capacity_max = "512GiB"
|
|
|
|
capability {
|
|
access_mode = "multi-node-multi-writer"
|
|
attachment_mode = "file-system"
|
|
}
|
|
|
|
# Optional: for 'nomad volume create', specify mount options to validate for
|
|
# 'attachment_mode = "file-system". Registering an existing volume will record
|
|
# but ignore these fields.
|
|
mount_options {
|
|
mount_flags = ["rw"]
|
|
}
|
|
|
|
parameters {
|
|
# Available options: https://github.com/s3/s3-csi-driver/blob/master/pkg/driver/mounter_s3.go
|
|
# By default, collection is the `volume ID` returned from the Create Volume gRPC call. Nomad calls this the
|
|
# External ID of the volume. "example" here overrides that.
|
|
collection = "example"
|
|
replication = "000"
|
|
# By default, path is "/buckets/<volume ID>", where `volume ID` is the value returned from the Create Volume gRPC
|
|
# call that Nomad calls the External ID. Do not use relative paths (paths that start with something other than /)
|
|
# They will will not work properly.
|
|
# When `path` is outside of the default path - `/buckets/<volume ID>` - the default path bucket will still be
|
|
# created, but remain empty. Since capabilities checks are tied to the default path of the volume, they may not
|
|
# provide the expected results.
|
|
path = "/buckets/example"
|
|
}
|