Heads up: PR [1913] got approved. If there are no more comments, I'm going
to merge tomorrow (EDT).
[1913] https://github.com/apache/polaris/pull/1913
Cheers,
Dmitri.
On Fri, Jun 27, 2025 at 8:47 PM Dmitri Bourlatchkov
wrote:
> I added a separate STS endpoint property to
> https://github.com/a
I added a separate STS endpoint property to
https://github.com/apache/polaris/pull/1913
Cheers,
Dmitri.
On Wed, Jun 25, 2025 at 7:59 PM Dmitri Bourlatchkov
wrote:
> Thanks for the feedback, Adnan!
>
> I was initially thinking of deferring separating STS and S3 endpoints to a
> later PR, but giv
Thanks for the feedback, Adnan!
I was initially thinking of deferring separating STS and S3 endpoints to a
later PR, but given interest, I'll add it to the current PR to reduce the
number of API changes over time.
Cheers,
Dmitri.
On Wed, Jun 25, 2025 at 1:28 PM Adnan Hemani
wrote:
> +1 on over
+1 on overall idea
Comment however on keeping the same endpoint for STS and S3 - there may be
a customer use case (I have seen this before for similar use cases) where
the S3 bucket is not in the same region as the STS endpoint that has been
exposed to the Polaris server. In that case, you really
+1, I think this is a good idea.
If there is a similar concept for the other storage types, could we
consider adding that too?
*
https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints
--EM
On Tue, Jun 24, 2025 at 9:23 PM Dmitri Bourlatchkov
wrote:
> Hi All,
>
> I pro
Hi All,
I propose to add an `endpoint` optional parameter to AwsStorageConfigInfo
in PR [1913].
The main idea is to support non-AWS S3 implementations for [1530].
Existing classes related to supporting S3 Polaris are coded to the AWS SDK,
which supports setting STS endpoints. Therefore, it seems
