GitHub user Ma77Ball edited a comment on the discussion: Recent changes about MinIO
Quick update after actually trying the interim swap, plus a finding that changes what I'd recommend. - **The MinIO images are already gone, not just deprecated.** `minio/minio` and `minio/mc` no longer resolve on Docker Hub at all, including the tags we pin (`RELEASE.2025-02-28T09-55-16Z` / `RELEASE.2025-05-21T01-59-54Z`) and even `:latest`. So CI and local-dev bring-up are broken right now for anyone without cached layers, not "soon." - **Every still-available MinIO is AGPL, which matters for us as an Apache project.** MinIO's server and the `mc` client have been AGPL-3.0 since 2021, so every drop-in rebuild inherits it: `pgsty/silo`, `pgsty/minio`, Chainguard's rebuild, and `bitnamilegacy/minio` all ship AGPL software (ASF Category X). Note the `mc` client we use for bucket-init is AGPL too, so that step has to move to a permissive client (e.g. `amazon/aws-cli`, Apache-2.0) regardless of which server we choose. - **`bitnamilegacy/minio` is the worst of both worlds.** It's pullable but frozen at `2025.5.24` and EOL (Bitnami retired the free catalog in Aug 2025 and stopped updating it), so it still carries CVE-2025-62506, and it's not a clean drop-in (its own entrypoint, UID 1001, data at `/bitnami/minio/data`). - **`pgsty/minio` is the cleanest AGPL option.** It patches the CVE (fresh from-source rebuild, `RELEASE.2026-08-04`) and is a genuine 5-line drop-in (keeps `MINIO_ROOT_USER` and `/minio/health/live`), but it's still AGPL, so it doesn't get us to Apache-compliant. My suggestion is to go with **RustFS** (Apache-2.0) on `main` for now. Of the Apache-2.0 stores we evaluated it's the least-change path: it speaks the S3 API on 9000 with a `/data` volume, so lakeFS, Iceberg/lakekeeper, and any S3 client talk to it the same way. The delta from MinIO is small but real: credential env vars (`RUSTFS_ACCESS_KEY`/`RUSTFS_SECRET_KEY`), the healthcheck (it doesn't expose `/minio/health/live`), and moving bucket-init from `mc` to `aws-cli`. The one caveat is maturity: RustFS is currently `v1.0.0-rc.6`. That's fine for unblocking `main` and dev, but I'd hold off backporting to the release branches until it's hardened, specifically until we've validated the less-common S3 surface it has to satisfy for us (lakeFS presigned URLs, Iceberg remote signing / path-style access) under our integration tests, and ideally until there's a GA release. So: land RustFS on `main` now to get CI green and dev working again, run it there for a while, and treat the backport as a separate follow-up gated on that hardening. GitHub link: https://github.com/apache/texera/discussions/3998#discussioncomment-18418659 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
