minio: repin to pgsty's fork, build the runtime sidecar, move data off HAL's live drive #57

2026-09-24T15:56:46Z

jschoubben commented

2026-09-24 15:56:46 +00:00

minio/minio and minio/mc were pulled from all public registries on 2026-09-11 (hq issue 113); repinned the server to docker.io/pgsty/minio@sha256:b6bfe7239bfc83fb90d31612d9704d86039dd714f7904b3f1ad68f211e602372, the working community fork.

The runtime sidecar had no Dockerfile and no build section at all — added both, following the same client/tools/provisioner tsc shape every other converted module (e.g. umami) uses. Verified with a real build against this branch: produced artifact-store://minio/runtime@sha256:857b27d3d2645c6f2865d651f78615d5d6b4fac730e123be9e1184045ae4df03.

The important fix: the data resource pointed directly at /services/minio/data/data1-1 — one of HAL's live 8-drive erasure-coded array, with no independent redundancy of its own. Starting this module against that path would have written mesh-managed data straight into live production storage the mesh doesn't own. Moved to a fresh, empty, mesh-owned directory (/var/lib/minio-store); the actual data migration happens over the S3 API (rclone), not by sharing a disk path.

New image runs as root by default (no MINIO_USERNAME/MINIO_UID set in the manifest's env, confirmed against the image's own docker-entrypoint.sh), matching this module's existing directory resources — no owner override needed, unlike postgres.

minio/minio and minio/mc were pulled from all public registries on 2026-09-11 (hq issue 113); repinned the server to `docker.io/pgsty/minio@sha256:b6bfe7239bfc83fb90d31612d9704d86039dd714f7904b3f1ad68f211e602372`, the working community fork. The runtime sidecar had no `Dockerfile` and no `build` section at all — added both, following the same client/tools/provisioner `tsc` shape every other converted module (e.g. `umami`) uses. Verified with a real build against this branch: produced `artifact-store://minio/runtime@sha256:857b27d3d2645c6f2865d651f78615d5d6b4fac730e123be9e1184045ae4df03`. **The important fix:** the `data` resource pointed directly at `/services/minio/data/data1-1` — one of HAL's live 8-drive erasure-coded array, with no independent redundancy of its own. Starting this module against that path would have written mesh-managed data straight into live production storage the mesh doesn't own. Moved to a fresh, empty, mesh-owned directory (`/var/lib/minio-store`); the actual data migration happens over the S3 API (rclone), not by sharing a disk path. New image runs as root by default (no `MINIO_USERNAME`/`MINIO_UID` set in the manifest's env, confirmed against the image's own `docker-entrypoint.sh`), matching this module's existing directory resources — no `owner` override needed, unlike postgres.

jschoubben added 1 commit 2026-09-24 15:56:46 +00:00

minio: repin to pgsty's fork, build the runtime sidecar, move data off HAL's live drive 35e8a3fe19

minio/minio and minio/mc were pulled from all public registries on 2026-09-11;
pgsty's fork is the working replacement (hq issue 113). The runtime sidecar
had no Dockerfile and no build section at all — added, following the same
tsc-over-client/tools/provisioner shape every other converted module uses.

The data resource pointed straight at /services/minio/data/data1-1, one of
HAL's live 8-drive erasure-coded array — starting this module would have
written into production storage the mesh doesn't own. Moved to a fresh,
empty, mesh-owned directory; the actual data migration happens over the S3
API (rclone), not by sharing a disk path.

jschoubben referenced this pull request

2026-09-24 16:14:40 +00:00

minio: pin the server image to the maintained fork #56

jschoubben merged commit 49c5903861 into main

2026-09-24 16:15:09 +00:00

jschoubben deleted branch fix/minio-repin-and-move-off-hal-data

2026-09-24 16:15:09 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#57