Screenshots
csi-s3-archiver in action
What the driver looks like once it is running: The optional statistics page, and the command sequence from installing it to seeing a file appear in a bucket.
The statistics page#
Set S3A_WEBUI_PORT and the driver serves a read-only page: Uploads per hour and per day,
bytes archived, retries, permanent failures with the S3 error that caused them, and per-node
queue depth and volume counts. It is off unless the port is set.

Point S3A_WEBUI_PEERS at a headless Service and any pod renders the whole cluster: Each one
fetches its siblings and merges by node id. Discovery is plain DNS rather than the Kubernetes
API, which is what keeps the driver's ServiceAccount empty. The capture above is three drivers
on one network, aggregated by the one serving the page, which is also what the end-to-end suite
asserts against a two-node cluster.

Recordings#
Five short recordings of the command sequence: Installing the DaemonSet with kustomize, the same
thing with Helm, archiving a file, shipping a growing log with appendStrategy: segments, and
what a rejected attribute looks like.





These are scripted reproductions rendered from a checked-in script, not captures of a live cluster: The commands, the log format and the error text all come from the code, but no cluster was recorded. They will be replaced with real captures once the end-to-end suite runs a cluster on every build.