Hi Robert,

Thanks for sharing this. I wasn't familiar with Floci, but it looks very
interesting.

Since it is MIT licensed, it’s a good fit from a legal standpoint. It also
seems like a great candidate for our integration tests, especially given
that it functions more as an AWS emulator than just an object store.

Regards,
JB


On Mon, Jun 29, 2026 at 7:47 PM Robert Stupp <[email protected]> wrote:

> 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
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
>

Reply via email to