Reviving this thread with one more option, specifically for the test side.
I agree with the distinction made earlier in the thread: the best backend
for getting-started examples and the best backend for integration tests do
not have to be the same thing.
For tests that currently rely on MinIO because they need S3 plus STS/IAM, I
think Floci [1] [2] is worth evaluating as a replacement:
Unlike RustFS, Garage, or other S3-compatible stores, Floci is an AWS
emulator rather than only an object-store implementation.
That means the interesting surface for these tests is not just S3 CRUD, but
S3 together with IAM, STS, session credentials, policy evaluation, KMS, and
Secrets Manager.
That seems closer to what Polaris needs for credential vending and related
cloud integration coverage.
I would not suggest switching everything in one step. A safer migration
plan could be:
1. Add a small Floci-backed testcontainer/helper next to the existing MinIO
helper.
2. Port one or two MinIO-based credential-vending tests to Floci without
removing the MinIO tests.
3. Explicitly check the behavior we care about:
- STS AssumeRole works with vended credentials
- session policies are enforced
- denied S3 operations fail where expected
- path-style and virtual-host-style access behavior is understood
- existing MinIO-specific workarounds, such as KMS limitations, are
either
still needed or can be removed for Floci
4. If the coverage is at least equivalent, migrate the remaining STS/IAM
MinIO tests.
5. Only then remove the MinIO testcontainer usage that is no longer needed.
There may also be a broader testing upside if the AWS spike works.
The Floci suite is not limited to AWS:
- floci-gcp [3] claims Cloud Storage, IAM, Secret Manager, and Cloud KMS
support, and
- floci-az [4] claims Blob Storage and Key Vault support.
All three advertise very fast startup / low idle memory, so this could
reduce test duration versus heavier service containers.
I would keep that as a follow-up benefit rather than the first migration
goal, though.
For any later Azure/GCP migration, we should make provider-specific auth
part of the spike rather than assuming parity:
- AWS: STS AssumeRole, session policies, IAM allow/deny behavior,
KMS/Secrets Manager where relevant.
- GCP: Cloud Storage plus IAM, Secret Manager, and KMS behavior used by
Polaris.
- Azure: Blob Storage plus Key Vault, and explicit SAS-token coverage
because
SAS support is not prominent in the top-level floci-az docs.
This would keep the quickstart discussion separate.
Ozone may still be the better long-term fit for examples if/when its STS
story is complete enough, especially because it is an ASF project.
But for CI/integration tests that need an AWS-shaped local service, Floci
seems like a strong candidate to evaluate.
Robert
[1] https://floci.io/
[2] https://github.com/floci-io/floci
[3] https://github.com/floci-io/floci-gcp
[4] https://github.com/floci-io/floci-az
On Tue, Jan 27, 2026 at 9:05 AM Yong Zheng <[email protected]> wrote:
> sounds good.
>
> Thanks,
> Yong
>
> > On Jan 26, 2026, at 9:03 PM, Yufei Gu <[email protected]> wrote:
> >
> > Thanks a lot for digging deep on it, Yong! Given that virtual host
> style is
> > the default for AWS s3[1], maybe we will still need it for s3 compatible
> > storage in the long term. I think we could work with the RustFS community
> > to get it resolved, while gradually migrating from MinIO to RustFS for
> > tests.
> >
> > 1.
> >
> https://github.com/apache/polaris/blob/0b54f7046295ff19d434f9f0bd47b0b612be51a5/spec/polaris-management-service.yml#L1146
> >
> > Yufei
> >
> >
> >> On Mon, Jan 26, 2026 at 7:05 AM Yong Zheng <[email protected]> wrote:
> >>
> >> Hello,
> >>
> >> So in MinioContainer.java, we have following:
> >> ```
> >> private S3Client createS3Client() {
> >> return S3Client.builder()
> >> .httpClientBuilder(UrlConnectionHttpClient.builder())
> >> .applyMutation(builder ->
> >> builder.endpointOverride(URI.create(s3endpoint())))
> >> .applyMutation(builder -> region.ifPresent(r ->
> >> builder.region(Region.of(r))))
> >> // .serviceConfiguration(s3Configuration(s3PathStyleAccess,
> >> s3UseArnRegionEnabled))
> >> // credentialsProvider(s3AccessKeyId, s3SecretAccessKey,
> >> s3SessionToken)
> >> .credentialsProvider(
> >>
> >> StaticCredentialsProvider.create(AwsBasicCredentials.create(accessKey(),
> >> secretKey())))
> >> .build();
> >> }
> >> ```
> >>
> >> So we are not enforcing one or the other for access style which it will
> be
> >> default (which if virtual host style access based on what i recalled).
> >>
> >> Thus, with simple changes I mentioned above, the test cases with path
> >> style will work (PolarisRestCatalogMinIOIT.java) as we are setting
> >> setPathStyleAccess to true implicitly:
> >> ```
> >> protected StorageConfigInfo getStorageConfigInfo() {
> >> AwsStorageConfigInfo.Builder storageConfig =
> >> AwsStorageConfigInfo.builder()
> >> .setStorageType(StorageConfigInfo.StorageTypeEnum.S3)
> >> .setPathStyleAccess(true)
> >> .setEndpoint(endpoint)
> >> .setAllowedLocations(List.of(storageBase.toString()));
> >>
> >> return storageConfig.build();
> >> }
> >> ```
> >>
> >> The problem is RestCatalogMinIOSpecialIT.java where we have couple place
> >> where we are testing for virtual host style access such as following:
> >> ```
> >> @ParameterizedTest
> >> @CsvSource("true, true,")
> >> @CsvSource("false, true,")
> >> @CsvSource("true, false,")
> >> @CsvSource("false, false,")
> >> @CsvSource("true, true, VENDED_CREDENTIALS")
> >> @CsvSource("false, true, VENDED_CREDENTIALS")
> >> public void testAppendFiles(
> >> boolean pathStyle, boolean stsEnabled, AccessDelegationMode
> >> delegationMode)
> >> throws IOException {
> >> ```
> >>
> >> Thus, if it is okay to not have tests cover virtual host, I can remove
> >> them and switch to rustfs testcontainers (similar to the minio one but
> >> couple lines changes) and do the final test. From getting-start example,
> >> STS is all working as I am setting vended credentials implicitly in the
> >> spark command (
> >> https://github.com/apache/polaris/tree/main/getting-started/rustfs):
> >> ```
> >> --conf
> >>
> spark.sql.catalog.polaris.header.X-Iceberg-Access-Delegation=vended-credentials
> >>
> >> ```
> >>
> >> Thanks,
> >> Yong Zheng
> >>
> >>
> >>> On 2026/01/26 02:10:10 Dmitri Bourlatchkov wrote:
> >>> Thanks for the analysis, Yong!
> >>>
> >>> I do not think we have any MinIO-based tests that rely on virtual
> >>> host-stype access... I may be mistaken, though... Did you come across
> any
> >>> specific cases like this?
> >>>
> >>> IIRC all MinIO-based examples and tests use path-style access.
> >>>
> >>> Just to confirm, STS (cred. vending) works with RustFS, right?
> >>>
> >>> Thanks,
> >>> Dmitri.
> >>>
> >>>> On Sat, Jan 24, 2026 at 11:12 PM Yong Zheng <[email protected]>
> wrote:
> >>>
> >>>> So I spent some time on this today. With path style access, rustfs
> will
> >>>> work 100% with couple lines changes. However, when dealing with
> virtual
> >>>> host style access, it is not happy with testcontainer due to
> >> testcontainer
> >>>> map a random port to host and rustfs is very restrict on server
> domains
> >>>> (could be bug if not intensional). Take an example, when I have rustfs
> >>>> mapped to port 9000 and testcontainer maps it to 62226 (random
> selected
> >>>> port), the health check happens on localhost:62226 which is not
> >> something
> >>>> we can set ahead of time for RUSTFS_SERVER_DOMAINS. Same observation
> >> had
> >>>> being reported in https://github.com/rustfs/rustfs/issues/308 where
> >>>> others confirm:
> >>>> ```
> >>>> ...I tried the domain name method again. When configuring
> >>>> RUSTFS_SERVER_DOMAINS, if the domain name port is not 443, you need to
> >> fill
> >>>> in the port as well, for example, test.rustfs.cn:9000.
> >>>> ```
> >>>> But with testcontainer, this will map to some random port on host as
> >>>> describe above then throw InvalidBucketName error.
> >>>>
> >>>> Another issue is https://github.com/rustfs/rustfs/issues/1593 where
> >>>> rustfs thinks that mapping mentioned above is a bucket name.
> >>>>
> >>>> That being said, if we want to change our user facing getting-started
> >>>> example from minio to rustfs, it will work 100%. However, we can't
> >> change
> >>>> our integration tests from minio to rustfs if we need to continue
> >> cover the
> >>>> tests on virtual host style access.
> >>>>
> >>>> Thanks,
> >>>> Yong Zheng
> >>>>
> >>>> On 2026/01/19 19:36:48 Yufei Gu wrote:
> >>>>> I think it's a good plan to distinguish between getting-started
> >> examples
> >>>>> and integration tests, esp. if RustFS is much faster. Thanks Dmitri.
> >>>>> Will current integration tests fail if we switch to RustFS from
> >> minio?
> >>>>>
> >>>>
> >>
> https://github.com/apache/polaris/blob/5e5779f115472fa8614a6820b1e178520d927012/integration-tests/build.gradle.kts#L70-L70
> >>>>>
> >>>>> Yufei
> >>>>>
> >>>>>
> >>>>> On Mon, Jan 19, 2026 at 11:23 AM Dmitri Bourlatchkov <
> >> [email protected]>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Yufei,
> >>>>>>
> >>>>>> From my POV we need some storage for "getting started" examples and
> >>>> some
> >>>>>> storage for CI.
> >>>>>>
> >>>>>> They may be the same or different.
> >>>>>>
> >>>>>> I think Apache Ozone is preferable for examples (when it supports
> >> STS)
> >>>>>> because it's also inside the ASF and examples do not have to be as
> >>>> lean as
> >>>>>> containers used in CI.
> >>>>>>
> >>>>>> IMHO, RustFS looks promising for CI due to simplicity /
> >> performance...
> >>>> but
> >>>>>> it remains to be tested :)
> >>>>>>
> >>>>>> As long as the RustFS project remains active and aligned with S3
> >> API
> >>>>>> changes, I think it does not matter so much that it is not an ASF
> >>>> project.
> >>>>>> It is released under ALv2 [1]
> >>>>>>
> >>>>>> [1] https://github.com/rustfs/rustfs
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Dmitri.
> >>>>>>
> >>>>>> On Mon, Jan 19, 2026 at 2:13 PM Yufei Gu <[email protected]>
> >> wrote:
> >>>>>>
> >>>>>>> Given STS is an essential requirement for s3 compatible storage
> >>>>>> validation,
> >>>>>>> waiting for Ozone is reasonable to me. RustFS is also a good
> >>>> candidate if
> >>>>>>> it's faster and supports STS. With that, are we trying to test
> >> both
> >>>> Ozone
> >>>>>>> and RustFS as a long term solution?
> >>>>>>>
> >>>>>>> Yufei
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Jan 19, 2026 at 8:14 AM Jean-Baptiste Onofré <
> >>>> [email protected]>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi Dmitri,
> >>>>>>>>
> >>>>>>>> That’s a fair point. Since we are discussing the quickstart
> >> guide,
> >>>>>>> ensuring
> >>>>>>>> a consistent message and a positive user experience is
> >> essential.
> >>>>>>>>
> >>>>>>>> While I don't have a strong preference, I lean toward Apache
> >> Ozone
> >>>> as
> >>>>>> it
> >>>>>>> is
> >>>>>>>> an ASF project, which would help us avoid a similar situation
> >> to
> >>>> the
> >>>>>> one
> >>>>>>> we
> >>>>>>>> are currently facing with MinIO.
> >>>>>>>>
> >>>>>>>> That said, if RustFS is faster to set up and works well with
> >>>> minimal
> >>>>>>>> effort, I am completely fine with that approach.
> >>>>>>>>
> >>>>>>>> Thanks!
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> JB
> >>>>>>>>
> >>>>>>>> On Mon, Jan 19, 2026 at 3:59 PM Dmitri Bourlatchkov <
> >>>> [email protected]>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi All,
> >>>>>>>>>
> >>>>>>>>> The latest MinIO images work well for Polaris tests and
> >> demos.
> >>>>>>>>>
> >>>>>>>>> It might still be worth proactively trying newer S3
> >>>> implementations
> >>>>>>> like
> >>>>>>>>> RustFS and/or SeaweedFS (although I have not personally tried
> >>>> them
> >>>>>> out
> >>>>>>>> with
> >>>>>>>>> Polaris yet).
> >>>>>>>>>
> >>>>>>>>> Even though we may prefer Ozone as the main storage in
> >> examples
> >>>> when
> >>>>>> it
> >>>>>>>>> supports STS, validating other S3 implementations could be
> >>>> helpful
> >>>>>> for
> >>>>>>>>> Polaris end users.
> >>>>>>>>>
> >>>>>>>>> Also, I expect RustFS to be faster and less cumbersome to
> >> set up
> >>>> than
> >>>>>>>>> Ozone, which could be an advantage for integration tests in
> >> CI.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Dmitri.
> >>>>>>>>>
> >>>>>>>>> On Mon, Jan 19, 2026 at 6:03 AM Jean-Baptiste Onofré <
> >>>>>> [email protected]>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> I know the Ozone community is discussing to have STS full
> >>>> support
> >>>>>> for
> >>>>>>>>> 2.2.0
> >>>>>>>>>> release.
> >>>>>>>>>>
> >>>>>>>>>> So, I think it's reasonable to keep minio for now waiting
> >> ozone
> >>>>>>> 2.2.0.
> >>>>>>>>>>
> >>>>>>>>>> Thoughts ?
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> JB
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jan 19, 2026 at 3:59 AM Yong Zheng <
> >> [email protected]>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Adnan and JB,
> >>>>>>>>>>>
> >>>>>>>>>>> I took a closer look at Ozone and it doesn't appear STS
> >> is
> >>>> fully
> >>>>>>>>>> supported
> >>>>>>>>>>> yet for Ozone:
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/ozone/blob/master/hadoop-hdds/docs/content/design/ozone-sts.md
> >>>>>>>>>> .
> >>>>>>>>>>> In this case, do we still wan to cut over the getting
> >> start
> >>>>>> example
> >>>>>>>> to
> >>>>>>>>>>> Ozone one instead of MinIO?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Yong Zheng
> >>>>>>>>>>>
> >>>>>>>>>>> On 2026/01/14 23:32:11 Adnan Hemani via dev wrote:
> >>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'd hope that we can pivot to Ozone and hide the
> >> additional
> >>>>>>>>> adaptation
> >>>>>>>>>>>> behind our setup scripts.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's a shame that my fears came true about relying on a
> >>>>>> provider
> >>>>>>>> who
> >>>>>>>>> is
> >>>>>>>>>>>> actively trying to sell the managed version of their
> >>>> product
> >>>>>>>> shutting
> >>>>>>>>>>> down
> >>>>>>>>>>>> their OSS functionalities [1]. Any alternatives we
> >>>> consider, in
> >>>>>>> my
> >>>>>>>>>>> opinion,
> >>>>>>>>>>>> should take this experience into consideration.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm still not against reverting back to using local FS
> >> for
> >>>> the
> >>>>>>>>>> Quickstart
> >>>>>>>>>>>> experience. If all the alternatives only complicate
> >> things
> >>>> for
> >>>>>>> the
> >>>>>>>>> end
> >>>>>>>>>>>> user, then it will be a poor Quickstart experience -
> >> and
> >>>> that's
> >>>>>>>> much
> >>>>>>>>>>> worse
> >>>>>>>>>>>> than giving more functionality in Quickstart but users
> >> not
> >>>>>>> knowing
> >>>>>>>>> how
> >>>>>>>>>> to
> >>>>>>>>>>>> actually use it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best,
> >>>>>>>>>>>> Adnan Hemani
> >>>>>>>>>>>>
> >>>>>>>>>>>> [1] https://github.com/apache/polaris/pull/2976
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Jan 9, 2026 at 6:58 AM Jean-Baptiste Onofré <
> >>>>>>>> [email protected]
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, Ozone supports STS, that's why I mentioned it.
> >> It's
> >>>>>>> probably
> >>>>>>>>>> close
> >>>>>>>>>>>>> enough to minIO (even if some "adaptation" might be
> >>>> required
> >>>>>>> for
> >>>>>>>>>> STS).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Just my $0.01
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards
> >>>>>>>>>>>>> JB
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Jan 9, 2026 at 2:15 AM Yufei Gu <
> >>>>>> [email protected]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Agreed with Dmitri that STS is essential in this
> >> case,
> >>>>>>>> otherwise
> >>>>>>>>> a
> >>>>>>>>>>> local
> >>>>>>>>>>>>>> file system will be good enough.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> AFAIK, Apache Ozone supports STS starting from
> >> 2.1.0,
> >>>>>>>>>>>>>> https://ozone.apache.org/release/2.1.0/.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yufei
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Thu, Jan 8, 2026 at 4:55 PM Dmitri Bourlatchkov
> >> <
> >>>>>>>>>> [email protected]
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi François,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I could not find any mention of STS / AssumeRole
> >> in
> >>>>>>> GarageHQ
> >>>>>>>>> docs
> >>>>>>>>>>>>> (really
> >>>>>>>>>>>>>>> quick looks), so I assume it does not support
> >> STS...
> >>>> Do
> >>>>>> you
> >>>>>>>>> know
> >>>>>>>>>>> for
> >>>>>>>>>>>>>> sure?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> STS is pretty important for ease of use in
> >> Polaris
> >>>>>> getting
> >>>>>>>>>> started
> >>>>>>>>>>>>> (i.e.
> >>>>>>>>>>>>>>> setup without STS is more involved).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>> Dmitri.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Thu, Jan 8, 2026 at 3:09 PM Francois Papon <
> >>>>>>>>> [email protected]
> >>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> About other solutions, I made some test to
> >> evaluate
> >>>>>>> GaragHQ
> >>>>>>>>> as
> >>>>>>>>>> an
> >>>>>>>>>>>>>>>> alternative to MinIO:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> https://garagehq.deuxfleurs.fr/
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I don't know if all the required
> >> functionnalities
> >>>> used
> >>>>>> by
> >>>>>>>>>>> Polaris are
> >>>>>>>>>>>>>>>> provided but for the test/quickstart part may
> >> be
> >>>> it can
> >>>>>>> do
> >>>>>>>>> the
> >>>>>>>>>>> job.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> François
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Le 08/01/2026 à 16:35, Adam Christian a écrit :
> >>>>>>>>>>>>>>>>> Thanks, folks! Great points! I do like the
> >> idea
> >>>> of
> >>>>>>> using
> >>>>>>>>>>> something
> >>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>> than MinIO.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> My only 2 cents: For the quickstart docker
> >>>> compose
> >>>>>>> file,
> >>>>>>>> I
> >>>>>>>>>>> believe
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>> should use object storage that can be
> >>>> automatically
> >>>>>>>>>> configured
> >>>>>>>>>>>>>> without
> >>>>>>>>>>>>>>>>> having to put in credentials. The goal of the
> >>>>>>> quickstart
> >>>>>>>> is
> >>>>>>>>>> to
> >>>>>>>>>>> have
> >>>>>>>>>>>>>>>> anyone
> >>>>>>>>>>>>>>>>> who has Docker running locally to be able to
> >>>> launch a
> >>>>>>>>>>>>> non-production
> >>>>>>>>>>>>>>>>> version of Polaris through a single command.
> >> It's
> >>>>>>>> targeted
> >>>>>>>>>> for
> >>>>>>>>>>>>> users
> >>>>>>>>>>>>>>> who
> >>>>>>>>>>>>>>>>> are just learning about Polaris. So, in my
> >>>> opinion,
> >>>>>>> this
> >>>>>>>>>> rules
> >>>>>>>>>>> out
> >>>>>>>>>>>>>> AWS
> >>>>>>>>>>>>>>>> S3.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> As long as we meet that criteria, I do think
> >> that
> >>>>>>>> changing
> >>>>>>>>>>> would be
> >>>>>>>>>>>>>>>>> appropriate. Thanks for bringing this up!
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Go community,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Adam
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Thu, Jan 8, 2026 at 9:16 AM Dmitri
> >>>> Bourlatchkov <
> >>>>>>>>>>>>>>>>> [email protected]> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi All,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Apache Ozone works well, AFAIK [1] but it
> >>>> certainly
> >>>>>>>>> requires
> >>>>>>>>>>> more
> >>>>>>>>>>>>>>> setup
> >>>>>>>>>>>>>>>>>> work than MinIO.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> WDYT about RustFS? [2]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://polaris.apache.org/in-dev/unreleased/getting-started/creating-a-catalog/s3/catalog-ozone/
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [2] https://github.com/rustfs/rustfs
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>>> Dmitri.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Thu, Jan 8, 2026 at 8:46 AM Jean-Baptiste
> >>>> Onofré
> >>>>>> <
> >>>>>>>>>>>>>> [email protected]>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hi Yong,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Thanks for bringing this to our attention.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I agree with your assessment regarding the
> >>>> recent
> >>>>>>>> changes
> >>>>>>>>>> to
> >>>>>>>>>>>>> MinIO
> >>>>>>>>>>>>>>> OSS.
> >>>>>>>>>>>>>>>>>> We
> >>>>>>>>>>>>>>>>>>> could evaluate Apache Ozone as a potential
> >>>>>>> alternative;
> >>>>>>>>>>> while STS
> >>>>>>>>>>>>>>> might
> >>>>>>>>>>>>>>>>>>> require more changes, I believe it’s worth
> >>>>>>>> investigating.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> In the short term, we could update the
> >>>> quickstart
> >>>>>>> guide
> >>>>>>>>> to
> >>>>>>>>>>> use
> >>>>>>>>>>>>> AWS
> >>>>>>>>>>>>>> S3
> >>>>>>>>>>>>>>>>>> while
> >>>>>>>>>>>>>>>>>>> we wait to finalize the Ozone integration.
> >>>>>>>>>>>>>>>>>>> About Ceph, that's a good idea, assuming we
> >>>> have
> >>>>>> the
> >>>>>>>> same
> >>>>>>>>>>> kind of
> >>>>>>>>>>>>>>>>>>> layout/experience.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>>>> JB
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Thu, Jan 8, 2026 at 7:49 AM Yong Zheng <
> >>>>>>>>>> [email protected]
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We have MinIO support as S3 compatible
> >>>> storage and
> >>>>>>>> this
> >>>>>>>>> is
> >>>>>>>>>>> great
> >>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>> allows users to quickly test out Apache
> >>>> Polaris
> >>>>>> as a
> >>>>>>>>>>> catalog and
> >>>>>>>>>>>>>>> write
> >>>>>>>>>>>>>>>>>>> to a
> >>>>>>>>>>>>>>>>>>>> S3 compatible storage. However, as MinIO
> >> is
> >>>> now
> >>>>>>> under
> >>>>>>>>>>>>> maintenance
> >>>>>>>>>>>>>>> mode
> >>>>>>>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>> for OSS (
> >>>>>>>>>> https://github.com/minio/minio?tab=readme-ov-file),
> >>>>>>>>>>> we
> >>>>>>>>>>>>>>> won't
> >>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>> able to get updated images from public
> >> image
> >>>>>>> registry,
> >>>>>>>>>>> should we
> >>>>>>>>>>>>>>>>>> consider
> >>>>>>>>>>>>>>>>>>>> switch our primary getting-start example
> >> to
> >>>>>>> non-MinIO
> >>>>>>>>> one
> >>>>>>>>>>>>> instead
> >>>>>>>>>>>>>>> (the
> >>>>>>>>>>>>>>>>>>>> current one is MinIO as backend:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/polaris/blob/main/getting-started/quickstart/docker-compose.yml
> >>>>>>>>>>>>>>>>>>> )?
> >>>>>>>>>>>>>>>>>>>> Without doing so, users will be likely
> >> pulling
> >>>>>> down
> >>>>>>>>>> outdated
> >>>>>>>>>>>>> MinIO
> >>>>>>>>>>>>>>>>>> images
> >>>>>>>>>>>>>>>>>>>> with critical CVEs couple months later for
> >>>> their
> >>>>>>> local
> >>>>>>>>>>> setup to
> >>>>>>>>>>>>>> play
> >>>>>>>>>>>>>>>>>>>> around. If using outdated MinIO is a
> >> concern
> >>>> as
> >>>>>> the
> >>>>>>>>>>>>> getting-start
> >>>>>>>>>>>>>>>>>>> example,
> >>>>>>>>>>>>>>>>>>>> maybe we should switch to the Ceph one (
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/polaris/blob/main/getting-started/ceph/docker-compose.yml
> >>>>>>>>>>>>>>>>>>> )
> >>>>>>>>>>>>>>>>>>>> but updated it to match the same layout?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> Yong Zheng
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
