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

+1 (non-binding) - Verified signature/checksum - All the tests passed Thanks Yufei for driving the release! Best regards, Jonas On Thu, Jul 3, 2025 at 6:23 AM William Hyun wrote: > +1 (non-binding) > > I verified the following: > - Source tarball (shasum and GPG signature) > - Build and test

[Discuss] Add Policy Privileges and PolicyGrant to Management Spec

Hi folks, I would like to propose extending the management API specification to add policy-related privileges and making Policy a valid securable for "addGrantToCatalogRole" and "revokeGrantFromCatalogRole". This could allow users to manage policy-related privileges via management APIs. Here is t

Re: [VOTE] Release Apache Polaris 0.10.0-beta-incubating (rc2)

+1 (non-binding) 1. Verified signatures and checksums 2. Build and local tests all look good. Best, Jonas On Tue, May 6, 2025 at 8:44 AM Prashant Singh wrote: > +1 > > 1. Verified checksums, signature, artifacts > 2. did manual testing with admin and server, works well ! > > Best, > Prashant S

Re: [DISCUSS] Deprecate Eclipse Link and make Relational JDBC as default

+1, excellent work on the JDBC implementation! On Fri, May 2, 2025 at 3:39 PM yun zou wrote: > +1 (non-binding) > > On Fri, May 2, 2025 at 3:21 PM Yufei Gu wrote: > > > +1 on deprecating the EclipseLink backend. > > > > Yufei > > > > > > On Fri, May 2, 2025 at 3:00 PM Prashant Singh > > wrote:

Re: [VOTE] Add 'inherited' and 'namespaces' Fields to GetApplicablePolicies API Response

, 2025 at 3:12 PM Yufei Gu wrote: > > > +1. Thanks Jonas for the change! > > Yufei > > > > > > On Sat, Apr 5, 2025 at 6:45 PM Honah J. wrote: > > > > > Hi folks, > > > > > > Thanks for the feedback and discussion so far. Based on o

Re: [VOTE] Add 'inherited' and 'namespaces' Fields to GetApplicablePolicies API Response

ate Honah! > > Upgrading my vote to +1 > > Cheers, > Dmitri. > > On Fri, Apr 4, 2025 at 7:54 PM Honah J. wrote: > > > Thank you for your comment. Based on our discussion, I renamed the new > > "namespaces" field to "namespace-path". This ch

Re: [VOTE] Add 'inherited' and 'namespaces' Fields to GetApplicablePolicies API Response

nue to vote. Thanks, Honah(Jonas) On Fri, Apr 4, 2025 at 4:42 PM Dmitri Bourlatchkov wrote: > +0 the PR looks ok to me, but I made a non-critical comment in GH. > > Thanks, > Dmitri. > > On Fri, Apr 4, 2025 at 5:23 PM Honah J. wrote: > > > Hi folks, > > &g

[VOTE] Add 'inherited' and 'namespaces' Fields to GetApplicablePolicies API Response

Hi folks, I'd like to raise a vote for adding `inhertied` and `namespaces` fields to GetApplicablePolicies' response. These fields give users more information about whether the effective policy is inherited from its parent and the namespaces where the effective policy is located. You can find more

[Discuss] Add 'inherited' and 'namespaces' Fields to GetApplicablePolicies API Response

Hi folks, I'd like to propose a change to our existing GetApplicablePolicies API endpoint (GET /v1/{prefix}/applicable-policies) and gather your feedback. Currently, this endpoint retrieves policies applicable to a given target (e.g., table or view), including those inherited from parent entities

Re: [ANNOUNCE] Welcome Dmitri Bourlatchkov, Dennis Huo and Yufei Gu to the Apache Polaris PPMC

Congratulations! Well deserved! Best regards, Honah (Jonas) On Thu, Mar 27, 2025 at 10:48 AM Anurag Mantripragada wrote: > Congratulations all. Great work! > > > ~ Anurag Mantripragada > > > On Mar 27, 2025, at 7:56 AM, Dmitri Bourlatchkov > wrote: > > > > Thanks all for the warm welcome :) >

Re: Clarification on Unique Entity Identifier in Polaris

the entityId must be unique across all types. > > On Wed, Mar 26, 2025 at 12:30 PM Eric Maynard > wrote: > > > I believe that entity ID by itself is meant to be a unique identifier. > > > > On Wed, Mar 26, 2025 at 12:27 PM Honah J. wrote: > > > > > Hi

Clarification on Unique Entity Identifier in Polaris

Hi folks, I have a question about what constitutes a unique identifier for an entity in Polaris in the future. Right now, `lookupEntity` takes catalogId, entityId, and typeCode, following a recent refactoring (in a PR ). On the other hand, `lookupEntit

Re: [VOTE] REST API changes for Catalog Federation - addition of ConnnectionConfigInto to ExternalCatalog

+1 (non-binding) Best, Honah (Jonas) On Tue, Mar 25, 2025 at 8:22 AM Yufei Gu wrote: > +1 > > Yufei > > > On Tue, Mar 25, 2025 at 8:03 AM Prashant Singh > wrote: > > > +1 (non-binding) > > > > Best, > > Prashant > > > > On Tue, Mar 25, 2025 at 7:01 AM Dmitri Bourlatchkov > > wrote: > > > > >

Re: Clear separation of REST APIs

Thanks for the discussion so far! 'iceberg-rest-catalog-open-api.yaml' is declared to be a 1:1 copy of > Iceberg's v.1.7.1 'open-api/rest-catalog-open-api.yaml', but in fact it > has already diverged beyond just code formatting. The iceberg-rest-catalog-open-api.yaml file should indeed be a 1:1 c

Policy Store: Introducing PolicyMappingRecord – Summary & PR for Review

Hi folks, Thanks, everyone, for the great discussion and feedback on the PolicyMappingRecord topic. To summarize, we have general agreement that we need a new record, PolicyMappingRecord, to represent and persist the relationship of a Policy Attachment (e.g., attaching a policy to a table). To su

Re: Endpoint prefix name for Generic Table Support in Apache Polaris

Hi everyone, Thanks Yun for initiating the discussion and Dmitri for the proposal! I think a similar question applies to Policy management APIs as well. In general, we need to figure out how we handle Polaris-native, non-Iceberg catalog-level APIs. > * /catalog/v1 - remains supported for Iceberg

[Proposal] Implementation of Policy Store in Apache Polaris

Hi everyone, I am working with Yufei on Policy Management in Apache Polaris. The idea has gained significant interest, and there have been many valuable discussions in the design doc

Re: [Proposal] Distinguish Iceberg vs non-Iceberg APIs in Polaris

> > On Tue, Jan 28, 2025 at 7:22 AM Dmitri Bourlatchkov > > wrote: > > > >> Using multiple YAML files per API / API area sounds good to me. > >> > >> We should definitely use the Iceberg REST API YAML without any > >> modifications to avoid acci

Re: [Proposal] Distinguish Iceberg vs non-Iceberg APIs in Polaris

Hi everyone, Thanks for the proposal and all the great discussion! I also agree that we should separate Polaris-only APIs from the IRC spec to keep the IRC spec consistent with the upstream version. I’d like to propose another way to achieve this, as some APIs may not need a separate prefix but ar

[Proposal] Add Policy Management APIs to Rest Catalog Spec

Hi everyone, I am Honah (Jonas), working with Yufei on Policy Management in Apache Polaris. Here is the design doc for reference. To support policy management, we propose a new set of APIs that enab