Hi everyone,
I have merged in https://github.com/mansehajsingh/polaris-tools/pull/4 to
give us a better framework for adding file import/export to the tool in the
future.
This basically puts the Polaris read/write source behind a common interface
that we can implement with new variations for diff
Hi Alex
I'm going through the PR now and I think the Quarkus security approach
seems fine. I was actually thinking of working on this previously myself.
> This shall be done by implementing a new HttpAuthenticationMechanism
that will pick the right authentication mechanism (internal token broker
Great points, Russell !
Let’s give priority to first time people, I like this ! (We did that last
time with the Xtable folks).
Agree about debates, it’s better if it happens on mailing list as it gives
visibility to everyone.
And we can always have dedicated meeting when needed.
Thanks !
Regards
+1 to prioritize newcomers.
+1 to timeboxing
Cheers,
Dmitri.
On Tue, Apr 15, 2025 at 1:55 PM Russell Spitzer
wrote:
> I'm strongly in favor of having a timeboxed Agenda. I do want to make sure
> we always poll new attendees first. I'm not sure this would fit into our
> agenda but the Parquet sy
Going with options 1 and 3 initially sounds good to me. This should
simplify current JDBC PRs too.
We can certainly add capabilities later, because having realm ID in the PR
does not preclude other deployment choices.
Cheers,
Dmitri.
On Tue, Apr 15, 2025 at 1:49 PM Michael Collado
wrote:
> My
I'm strongly in favor of having a timeboxed Agenda. I do want to make sure
we always poll new attendees first. I'm not sure this would fit into our
agenda but the Parquet sync usually does a roll-call and "what are you
interested in?" at the top of the hour. We probably have too many people
for tha
My $.02 is that Option 1 is entirely possible using a DataSource that
dynamically creates Connections as needed. Option 1 is nice because, as
Pierre said, it gives admins the ability to dynamically allocate resources
to different clients as needed.
Personally, I'm less inclined to option 3 just be
Hi all,
I'm in agreement with Pierre, JB and Dmitri's points. I’d like to add some
context from the Quarkus configuration angle:
Option 1, which involves distinct datasources, presents a challenge.
Quarkus requires all datasources to be present and fully configured at
build time. This requirement
Hi,
Here is the first PR then:
https://github.com/apache/polaris/pull/1373
I will start working on the second PR, but since it builds on top of the
first one, we'd need to review & approve it first.
Thanks,
Alex
On Tue, Apr 15, 2025 at 12:49 PM Robert Stupp wrote:
> +1
>
> The plan is sound
Hi folks,
In order to "structure" on Community Meetings, I propose to have the
following plan for the meetings, organized by themes:
1. Highlights (5mn):
all cool things we did during the last two weeks
2. Podling Governance (5/10mn):
Update about release, new committers, incubator report, s
Hi folks,
The three approaches should be transparent for end users.
According to the isolation that a realm is supposed to guarantee, I
think we should consider 1 and 2 (3 is maybe too light in terms of
strong isolation).
1 and 2 can be achieved by configuration: it could be a dedicated
database,
Hi Alex,
It sounds like a good plan :)
Thanks !
Regards
JB
On Mon, Apr 14, 2025 at 10:50 PM Alex Dutra
wrote:
>
> Hi all,
>
> A recently-reported bug [1] uncovered some serious issues with the JAX-RS
> authentication filters. Fixing this bug requires replacing the incriminated
> filters with pr
Thanks for your perspective, Pierre! You make good points and I agree with
them.
>From my POV, I'd add that we probably need to take deployment concerns into
account too.
If the deployment uses the database per realm approach (option 1) then
someone has to provide database connection parameters (
Hi Prashant
I guess the answer will depend on how easy it should be for Polaris to
support multi-tenancy.
A separate database per realm would allow administrators to limit the
amount of resources that a realm can consume (e.g. the maximum number of
database connections). Indeed, it would be one
+1
The plan is sound!
On 14.04.25 23:15, Dmitri Bourlatchkov wrote:
This plan SGTM! Thanks for working on this, Alex!
Cheers,
Dmitri.
On Mon, Apr 14, 2025 at 4:52 PM Alex Dutra
wrote:
Hi all,
A recently-reported bug [1] uncovered some serious issues with the JAX-RS
authentication filters.
Hi everyone,
We have two pending PRs to merge before cutting 0.10.0-beta release:
- https://github.com/apache/polaris/pull/1370
- https://github.com/apache/polaris/pull/1292
As a reminder, once 0.10.0-beta is out, we are starting our time boxed
releases cycle: one release every 3 or 4 weeks. The
16 matches
Mail list logo
