Re: Proposal: Secure Views for FGAC Dynamic Enforcement (based on prior Access Decision Exchange work)

Thanks for the shoutout although I believe my contribution has been quite modest as consisting mostly of providing some initial feedback, and I don't think I had a key part in the overall design. But I'm also excited by the recent interest surrounding FGAC with Robert's proposal[1] and this proposa

[VOTE] Release Apache Polaris 1.0.0-incubating (RC2)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc2 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc2 * https://github.com/apache/polaris/tre

Volunteers needed to run Azure and GCS tests for PR 1934

Hi All, PR [1934] appears to make a valuable refactoring. However, it would be nice to actually test the tests in an "independent" environment :) I ran tests for AWS. Would anyone have capacity to cover Azure and/or GCS? [1934] https://github.com/apache/polaris/pull/1934 Thanks, Dmitri.

Re: Polaris Community Sync on Events

Hi all, Thanks for the feedback. I've spent the last day or so trying to figure out what this suggestion (persisting events in the same transaction) means in terms of a potential implementation. Here's what I've got: * Not all potential auditable actions go to the persistence (e.g. actions on fede

Re: [DISCUSS] Adding endpoint to AwsStorageConfigInfo

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

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC1)

Cancelling RC1 due to the Helm Chart versioning fix. More context in https://github.com/apache/polaris/pull/1944 and https://lists.apache.org/thread/d1vf7xpn6nkzp8gbh417m8qb58tkpcqz Yufei On Wed, Jun 25, 2025 at 11:48 AM Yufei Gu wrote: > A quick correction: the correct tag name is > apache-po

Re: [DISCUSS] Polaris Delegation Service for Long-Running Tasks

Hi Anurag, Thank you for your interest and taking the time to review the design doc! To answer some of your questions: 1. The source of truth for all delegated tasks is within the Delegation Service's own persistence layer. 2. The current document abstracts away the implementation details of the

Re: [DISCUSS] Prepare for 1.0 Release

Update: I tested RC0 and it did NOT have this problem. The problem appears to exist only on `main`. The fix in [1945] makes sense in general, though. I'll leave the backport decision to you, Yufei. I guess we'll have to retest with RC1 in any case. [1945] https://github.com/apache/polaris/pull/

Re: [DISCUSS] Prepare for 1.0 Release

Agreed! We also need to change the server side config in that case. Yufei On Wed, Jun 25, 2025 at 3:32 PM Dmitri Bourlatchkov wrote: > Hi Yufei, > > I've just tested the admin tool locally and it does fail with "No bean > found for required type [interface javax.sql.DataSource]" on the current

Re: [DISCUSS] Prepare for 1.0 Release

Hi Yufei, I've just tested the admin tool locally and it does fail with "No bean found for required type [interface javax.sql.DataSource]" on the current `main`. I do not know what regressed, though. I think we have to fix this for 1.0. Cheers, Dmitri. On Wed, Jun 25, 2025 at 6:11 PM Yufei Gu

Re: [DISCUSS] Prepare for 1.0 Release

Thanks for raising this, Dmitri! One minor question, does this( https://github.com/apache/polaris/pull/1945/files#r2167723808) affect normal use cases beside Quick Start? If that's the case, we could have it in the 1.0.0 release. Yufei On Wed, Jun 25, 2025 at 2:57 PM Dmitri Bourlatchkov wrote:

Re: [DISCUSS] Prepare for 1.0 Release

Hi All, Do you think we should include this new issue into 1.0? https://github.com/apache/polaris/issues/1943 Thanks, Dmitri. On Mon, Jun 23, 2025 at 9:32 PM Yufei Gu wrote: > Thanks a lot for everyone working on this! Sent out the 1.0.0 RC0 release > vote mail! > > Yufei > > > On Mon, Jun 23

Re: [DISCUSS] Separate Helm charts release

Thanks for the summary, Yufei! +1 to all points (1 - 5). Re: 5: just to clarify - reverting to an old helm chart version with this version / tag scheme will mean reverting to an old Poalris binaries version, which is technically a downgrade. I do not think we discussed our approach to downgrades,

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Hi Dmitri, I agree with the "NONE" suggestion, I will send out the new version once PR 1931 is merged because as discussed on GH, we plan to use changes from 1931. Regarding the NULL_TYPE enum: In my experiences, it is always good to think about b

Re: Discussion: Adding NO_AUTH Support for Catalog Federation

Hi Dmitri, I agree with the "NONE" suggestion, I will send out the new version once PR 1931 is merged because as discussed on GH, we plan to use changes from 1931. Regarding the NULL_TYPE enum: In my experiences, it is always good to think about b

Re: [DISCUSS] Separate Helm charts release

Hi Yufei, Thanks for reviving this discussion! I am +1 on all your suggestions. Thanks, Alex On Wed, Jun 25, 2025 at 10:51 PM Yufei Gu wrote: > > Thanks Dmitri for raising this. Thanks all for the discussion. Can we > conclude this thread? Here are some points we discussed(1, 2, 3) + my > sugge

Re: [DISCUSS] Separate Helm charts release

Thanks Dmitri for raising this. Thanks all for the discussion. Can we conclude this thread? Here are some points we discussed(1, 2, 3) + my suggestion for versioning(4,5): 1. Publish the Helm Chart along with Polaris src/bin release. 2. Publish the Helm Chart to dist.apache.org 3. Using the same v

Re: Discussion Regarding Events Instrumentation - GH PR #1904

> Then we need to go back to square zero and ask ourselves what these events are useful for. To start with, I would point to the design doc from January and this ML thread from Dec

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

> > Zip and tarball binaries for `polaris-server` and `polaris-admin` are > missing in the Maven publication. > Dist contents [1] have inconsistent file name patterns, for example: * apache-polaris-1.0.0-incubating.tar.gz > * polaris-bin-1.0.0-incubating.tgz I believe binary archives should

Re: Discussion Regarding Events Instrumentation - GH PR #1904

I think we may be making too many assumptions about the semantics of an event being emitted and letting that paralyze us. If you're looking for an event to be emitted *iff* a table change is committed to the metastore, the current system simply does not support that use case: - BeforeTableCommi

Re: Discussion Regarding Events Instrumentation - GH PR #1904

Hi, > - AfterTableCommittedEvent tells you how many times the commit succeeded > and the server attempted to return a response to the client. Not quite: in the current design, it tells you the number of times the commit succeeded, minus the number of times the commit succeeded, but the persist

Proposal: Secure Views for FGAC Dynamic Enforcement (based on prior Access Decision Exchange work)

Hi everyone, We’d like to share a proposal to extend Iceberg's view capabilities to support Secure Views for Dynamic Policy Enforcement. This builds upon earlier discussion and proposal around Iceberg Spec Extensions for Data Access Decision Exchange

Re: Proposal: Secure Views for FGAC Dynamic Enforcement (based on prior Access Decision Exchange work)

Apologies for the broken link to the proposal : here you go [OSS] Secure Views for dynamic policy enforcement. Best, Prashant Singh On Wed, Jun 25, 2025 at 11:06 AM Prashant Singh wrote: > Hi ever

Re: [DISCUSS] Polaris Delegation Service for Long-Running Tasks

Hey Dmitri, Thank you for your comments! I would like to first clarify that while the initial use case is internal, we are not closing the door completely on having Delegation Service be accessible through user-driven clients. We would love this service to eventually be deployed and run independe

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC0)

Hi Yufei, I think having different micrometer versions in use in the admin tool and server is fine for 1.0. However, my impression is that those artifacts depend on two micrometer versions each at the same time, is that so? Could you clarify this (note: you mentioned an email attachment, but I do

Re: [VOTE] Release Apache Polaris 1.0.0-incubating (RC1)

A quick correction: the correct tag name is apache-polaris-1.0.0-incubating-rc1. All the provided links remain accurate. Yufei On Wed, Jun 25, 2025 at 11:44 AM Yufei Gu wrote: > Hi everyone, > > I propose that we release the following RC as the official > Apache Polaris 1.0.0-incubating releas

[VOTE] Release Apache Polaris 1.0.0-incubating (RC1)

Hi everyone, I propose that we release the following RC as the official Apache Polaris 1.0.0-incubating release. This corresponds to the tag: apache-polaris-1.0.0-incubating-rc0 * https://github.com/apache/polaris/commits/apache-polaris-1.0.0-incubating-rc1 * https://github.com/apache/polaris/tre

Re: [DISCUSS] Adding endpoint to AwsStorageConfigInfo

+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

Re: [DISCUSS] Adding endpoint to AwsStorageConfigInfo

+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