stions ATM,
> but I am willing to collaborate on PRs. To clarify: I mean
> if/elseif/elseif/... sequences for different logic per sub-type. I hope
> those could be converted to overridable (virtual) method calls (as an
> example).
>
> Cheers,
> Dmitri.
>
> On Thu, Jul 17, 20
A lot of the concerns seem to arise from the fact that Polaris essentially
has two distinct deployment modes:
1. Provide a highly isolated multi-tenant (multi-realm) Iceberg
REST service with a tightly curated set of secure integrations to external
dependencies
2. Provide a turnkey Iceberg REST se
Hey all,
I sketched out some design details for next-step features in Polaris
Federation based on discussion with Pooja, Rulin, Harish, and Teja:
https://docs.google.com/document/d/19Vm0Uy-EyEYtgd2-bZpPICODOB3rYQJvHeqL1ODOOLc/edit?tab=t.0
At a high level, currently the REST-based Federation MVP b
+1 to IMPLICIT.
Note, I would consider the Hadoop/HDFS one to actually also correctly be
following the conventions we described for IMPLICIT, because the Polaris
service/system environment can indeed be configured to make the Hadoop
FileSystem use whatever auth it wants, even Kerberos-based access
+1 (binding)
-Verified all checksums
-Verified compile from source tarball
-Verified setting feature configs
-Successfully tested federation with list fix
On Wed, Jul 2, 2025 at 11:57 AM Yufei Gu wrote:
> Hi everyone,
>
> I propose that we release the following RC as the official Apache Polaris
-1 (binding)
Given the nature of the broken "list" operations in federation towards
usability and the fairly straightforward already-merged fix to pick, my
vote is to cut a new RC6 for the fix.
On Tue, Jul 1, 2025 at 11:22 PM Dennis Huo wrote:
> Sorry for surfacing this late,
Sorry for surfacing this late, but I hadn't noticed
https://github.com/apache/polaris/issues/1848 before (already fixed at head
by Rulin's https://github.com/apache/polaris/pull/1849)
I can't remember whether we formally considered Federation bugs to be 1.0
blockers, but it's one of the big featur
+1 (binding)
1. Verified checksums
2. Verified build/test from source distribution
3. Verified server binary distribution
On Mon, May 19, 2025 at 2:40 PM Yufei Gu wrote:
> +1(binding)
>
> 1. Verified asc, sha512.
> 2. Build and test passed.
> 3. Verified both binary distributions, admin and ser
+1 (binding)
1. Verified checksums
2. Verified running server binary distribution with run.sh and
configuration overrides, feature flags per instructions under
https://polaris.apache.org/in-dev/unreleased/configuration/
On Mon, May 5, 2025 at 11:35 PM Jean-Baptiste Onofré
wrote:
> Hi Adnan
>
>
In general this sigv4 indirection control-flow should mirror the analogous
patterns we apply on the StorageConfigInfo side (and perhaps long-term we
can better consolidate the STS logic for the two), so I'd agree it's not
even necessarily federation-specific.
There's some precedent for the use-cas
the cache code to avoid any doubt that it is used
> only within the Resolver calls paths. Perhaps we could rename it to
> ResolverCache and make it a single-purpose class without a public
> interface... These are just some ideas, I have not given this option a lot
> of thought yet as I p
Hello all,
Following up from today's community sync where we were discussing 1.0
blockers, I just wanted to finalize discussion on
https://github.com/apache/polaris/issues/761 to check if everyone's aligned
on the current state of things.
My understanding is that the originally reported issues re
+1, thanks!
On Mon, Apr 7, 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 our PR discussion
> > about naming, we’ve simplified “namesp
Hello!
I wanted to continue discussion that had started during review of the
initial Catalog Federation API spec (
https://github.com/apache/polaris/pull/1026) regarding how we want to
handle secrets.
I drafted this document describing how secrets management fits in to
Catalog Federation, while e
t Singh
> > > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Prashant
> > > >
> > > > On Tue, Mar 25, 2025 at 7:01 AM Dmitri Bourlatchkov <
> di...@apache.org>
> > >
Correct, 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 folks,
> >
> > I have a question about what constitu
Hello all,
We've had some productive discussion in various places on the mailing list,
in the github PR, and in the live community sync now about the initial
minimal updates to the Polaris REST API (under the "management API") for
adding a ConnectionConfigInfo field to ExternalCatalogs to represen
Re: "non-transactional", I guess it's more descriptive to refer to this new
implementation as "AtomicOperationJdbcPersistence" if it's confusing to say
"non-transactional"; the key is simply that we don't expose any
"runInTransaction" to the AtomicOperationMetaStoreManager layer.
Regarding Robert'
Manager) and secret storage.
>
> However, that will likely lead to significant and non-backward-compatible
> changes in Admin API areas that deal with federated catalogs. I am
> personally fine with this approach. Still, I think it would be good to hear
> what other people think
Hi all,
For anyone who may not have seen the PR on github, just wanted to ensure
folks have a chance to give input on the mailing list here about the latest
API spec proposal for supporting Catalog Federation:
https://github.com/apache/polaris/pull/1026
This adds a ConnectionConfigInfo field to
This is great to hear, thanks for helping arrange this!
+1 to having this tool in Polaris and +1 inviting one of the original main
contributors of the code.
I don't feel too strongly about separate repo vs additional module, since I
could see pros/cons of either approach. Would be a bit cleaner t
it would be great to discuss.
> We can give time to anyone interested to read the proposals, and
> discuss next week ?
>
> Maybe we can do it on Thursday, Feb 13, 9am PST (same slot as Polaris
> Community Meeting) ?
>
> Thanks
> Regards
> JB
>
> On Tue, Feb 4, 2025 at
ion of
> handling concurrent reads / writes made by different instances of the
> Polaris Server. Would you be able to elaborate on that?
>
> Thanks,
> Dmitri.
>
> On Tue, Feb 4, 2025 at 2:03 PM Dennis Huo wrote:
>
> > Hello all,
> >
> > We've had s
For posterity,
https://docs.google.com/document/d/1U9rprj8w8-Q0SnQvRMvoVlbX996z-89eOkVwWTQaZG0/edit?tab=t.0#bookmark=id.cmp67w7aja0o
explains a bit about why the Postgres implementation hits this. To recap
from the doc comment:
1. The current Postgres impl naively follows the same design pattern a
Hello all,
We've had some discussions and github issues (
https://github.com/apache/polaris/issues/775,
https://github.com/apache/polaris/issues/766, etc) scattered between
community syncs, slack threads, etc., related to how to adapt the Polaris
persistence layer to new DB backends, so I'm hoping
ink: https://meet.google.com/ryj-mueq-csf
Thanks JB for setting it up!
On Mon, Jan 13, 2025 at 11:15 AM Russell Spitzer
wrote:
> +1 Works for me (meeting on thursday)
>
> On Sun, Jan 12, 2025 at 8:56 PM Dennis Huo wrote:
>
> > Ah so sorry, I meant to include the proposed date of Thur
t; > >
> > > > Cheers,
> > > > Dmitri.
> > > >
> > > > On Mon, Jan 13, 2025 at 2:38 AM Jean-Baptiste Onofré <
> j...@nanthrax.net>
> > > > wrote:
> > > >
> > > > > Hi folks,
> > > >
between catalogs. Wdyt?
>
> Thanks,
>
> Alex
>
>
> On Fri, Jan 10, 2025 at 3:36 AM Dennis Huo wrote:
> >
> > Hello!
> >
> > I wanted to kick off next steps to drive forward the design discussion
> for
> > Polaris Catalog Federation:
> >
>
Hello!
I wanted to kick off next steps to drive forward the design discussion for
Polaris Catalog Federation:
https://docs.google.com/document/d/1Q6eEytxb0btpOPcL8RtkULskOlYUCo_3FLvFRnHkzBY/edit?tab=t.0
In some of the prior community syncs I think folks expressed a desire to
have some dedicated d
I just filed https://github.com/apache/polaris/issues/540 to track this
feature request, and wrote up this document to try to better solidify our
terminology and concepts on related federation features, while also
sketching out a proposal for a basic MVP of catalog federation that could
be easily e
30 matches
Mail list logo
