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