Congratulations everyone for reaching this symbolic milestone!
Alex
Le ven. 11 juil. 2025 à 12:02, Jean-Baptiste Onofré a
écrit :
> Congrats everyone !
>
> FYI, I published the Docker images (for amd64 architecture for now, I
> will publish multi-arch asap):
> - Polaris server
> (
> https://hub
Hi,
I also have a preference for minikube – even if Kind has the ability of
launching multi-node clusters, which minikube can't do.
Historically, Kind was used in one single place: the run.sh script at the
root of the repo. I think it was chosen so that we can launch a local
Docker registry (cf.
+1 (non-binding)
Checked:
* Checksums & signatures
* Source release builds, passes tests, and has no binary files
* Binary release: server & admin tool both work
* Helm chart: helm verify, lint, pull & install work (the Docker image must
be manually built)
Thanks,
Alex
On Thu, Jul 3, 2025 at 5:
Hi all,
Thanks Adnan for the definition of read-based events – it wasn't clear for me.
> Adding a before and after event as part of a DB transaction isn't really
> useful - we should reduce to just one event emitted after.
Indeed, in this case the events table would look more like a CDC
commit
think we should use dist.apache.org for helm charts releases.
> >
> > Regards
> > JB
> >
> > Le ven. 31 janv. 2025 à 11:04, Alex Dutra
> > a
> > écrit :
> >
> > > Hi again,
> > >
> > > We also need to discuss hosting Helm char
ore like
> you describe. This would require significant code changes. Other
> EventListeners, such as one that sends events into a message queue,
> inherently won't be able to support that transactionality even if this
> third event is added. I don't see this as a reason to bloc
Hi,
To be honest, the decorator approach is nice to have, but I could live
without it.
What worries me the most right now is the design decision around
"after" events. That a "before" event could exist without the
corresponding "after" one, or even without the corresponding update to
the metastor
Hi Adnan, hi all,
> there are no issues in managing a horizontally-scaled or geo-distributed set
> of buffers.
I seriously doubt it. In case of a Kubernetes deployment, have you
considered what happens when a Pod is evicted? In the current PR,
there are some resource leaks, which means that the
Hi all,
Catching up quite late with this discussion thread, my apologies.
Trying to sum up my impressions so far:
We should definitely avoid parsing SQL and altering view definitions.
Instead it seems that Eric's proposal of defining FGAC policies with a
clear syntax and spec is a much more robus
Hi Robert, hi all,
I do agree with you that we need to distinguish between nightlies and
production-ready artifacts, mainly because these repositories will be
fed by fairly diverse pipelines: nightly images will be provided by an
automated pipeline with no guarantee whatsoever about the contents i
Congratulations Yun! Glad to have you on board!
Alex
On Thu, Jun 12, 2025 at 10:45 AM Jean-Baptiste Onofré wrote:
>
> Hi everyone,
>
> We are happy to announce Yun as new committer on the Apache Polaris podling.
>
> Thanks a lot Yun for your contributions and warm welcome !
>
> Regards
> JB on b
keeps the code simpler, avoids proxy lookups, and makes unit tests
> > > > cleaner.
> > > >
> > > > As a rule of thumb, we may inject a narrower scope only when we must.
> > > >
> > > > Yufei
> > > >
> > &
Hi all,
+1 to skip the 0.10 release.
Thanks,
Alex
On Sat, Jun 7, 2025 at 2:52 AM Dmitri Bourlatchkov wrote:
>
> Skipping the 0.10.0 release and going for 1.0.0 sounds good to me.
>
> Cheers,
> Dmitri.
>
> On Fri, Jun 6, 2025 at 6:49 PM Jean-Baptiste Onofré wrote:
>
> > Hi everyone,
> >
> > As
Hi Dmitri,
Thanks for bringing up this important topic.
I generally agree with your refactoring proposal, but with 2 caveats:
1) For an application-scoped bean exposing methods to retrieve realm-scoped
components (e.g., the "factory" beans that expose methods like
"getOrCreateXYZ") I think it's
> nullable?
>
> --EM
>
> On Mon, Jun 2, 2025 at 8:42 AM Alex Dutra
> wrote:
>
> > Hi all,
> >
> > > So now, the onus is on me, as the developer to write [...]
> >
> > But this remark is valid both ways, right? If the default is non-null
> >
Hi JB,
I agree that it doesn't feel safe to run Renovate on release branches
and risk dependency upgrades between release attempts. Besides, we can
always bump versions manually if needed.
So, +1 on your proposal to only run Renovate on main.
Thanks,
Alex
On Mon, Jun 2, 2025 at 5:58 PM Dmitri B
; > > > > > and returned from a Polaris method without validation, and the
> > > returned
> > > > > > value can reasonably be null, then the Polaris method should be
> > > > annotated
> > > > > > as @Nullable. However
Hi,
+1 (non-binding)
1) Source distribution
- Verified signatures
- Verified checksums
- Verified no binary files present
- Verified build: ./gradlew rat test
2) Binary distributions
- Verified signatures
- Verified checksums
- Downloaded, extracted server tgz
- Verified ./run.sh
eeps the out-of-the-box
> > visibility that keeps multi-tenant ops sane.
> > Dropping the tag outright trades day-to-day operability for a theoretical
> > scaling worry most users will never hit. Let’s keep it and offer an opt-out
> > instead.
> >
> > Yufei
> >
&g
Hi JB,
The report looks good. Thanks!
Alex
On Mon, May 26, 2025 at 4:49 PM Dmitri Bourlatchkov wrote:
>
> The report LGTM. Thanks for putting it together, JB!
>
> Cheers,
> Dmitri.
>
> On Mon, May 26, 2025 at 10:07 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi folks,
> >
> > I prepared the incubat
sers will never hit. Let’s keep it and offer an opt-out
> instead.
>
> Yufei
>
>
> On Fri, May 23, 2025 at 5:49 AM Alex Dutra
> wrote:
>
> > Hi,
> >
> > For reference the PR is here: https://github.com/apache/polaris/pull/1662
> >
> > Ale
Hi,
For reference the PR is here: https://github.com/apache/polaris/pull/1662
Alex
On Fri, May 23, 2025 at 2:42 PM Robert Stupp wrote:
>
> +1 on adding a config and default to false - and later entirely remove
> the "issue".
>
> Sounds like good plan to me!
>
>
log-based
> metrics), but I like the slow approach of adding a configuration flag,
> disabling it by default, then removing functionality as a best practice,
> anyway.
>
> Mike
>
> On Thu, May 22, 2025 at 11:39 AM Alex Dutra
> wrote:
>
> > Hi again,
> >
&
n-nullness may discourage null-checking, which is problematic as runtime
> null-checking isn't a thing.
>
> Yufei
>
>
> On Wed, May 21, 2025 at 9:52 AM Alex Dutra
> wrote:
>
> > Hi Eric,
> >
> > You're right that annotations don't change th
27;s needs.
Let me know your thoughts.
Alex
On Wed, May 21, 2025 at 3:57 PM Robert Stupp wrote:
>
> Ouch! That sounds very simple to exploit and quite serious.
>
> On 21.05.25 15:38, Alex Dutra wrote:
> > Also worth noting: http_server_requests_seconds_* metrics are generated
-null a developer should feel safe
> skipping a check for null, but otherwise they should handle null.
>
> I am a big fan of Optional and of trying to reduce the usage of null as
> much as possible though.
>
> On Wed, May 21, 2025 at 3:02 PM Alex Dutra
> wrote:
>
> > Hi al
Hi all,
A while ago, we had a discussion regarding which nullness annotations
to use and whether we should consider favoring non-null by default. I
would like to revive that discussion.
We are currently using the `jakarta.annotation` package consistently,
but the defaults are not clear: should we
investigate all metrics and reduce the cardinality of all
> of those as that can easily become a serious issue.
>
> On 21.05.25 11:42, Alex Dutra wrote:
> > Hi Mike,
> >
> > If you have around a hundred realms or more, imho you are already in
> > trouble.
&
er than
> > increasing the cardinality of every endpoint metric.
> >
> > Cheers,
> > Dmitri.
> >
> > On Thu, May 15, 2025 at 3:30 PM Alex Dutra >
> > wrote:
> >
> > > Hi all,
> > >
> > > I would like to suggest remov
Hi all,
I'm obviously +1 on Robert's proposals. Should we modify our
CONTRIBUTING.md guidelines?
Also, in the spirit of standardizing how commit messages should be
formatted, I suggest that we take a look at the Conventional Commits
spec [1].
This small spec is becoming more and more popular (I
Hi all,
To be honest my preference would be Option 4: a different image name
for everything that is "nightly" or "unstable". For example,
"apache/polaris-unstable" or "apache/polaris-admin-tool-nightly".
My reasoning is simple: make it almost impossible for a user to
accidentally deploy an unstab
Hi all,
I would like to suggest removing the "realm_id" metric tag entirely.
My concern is that this tag has the potential for high cardinality, which
is generally considered a bad practice when dealing with metrics. High
cardinality can lead to performance issues and increased memory usage.
Gra
Congrats everyone! Welcome aboard!
Le lun. 5 mai 2025 à 04:16, Omar Al-Safi a écrit :
> Welcome and congratulations!
>
> On Sun, May 4, 2025 at 7:54 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi everyone,
> >
> > We are very happy to announce new committers to the Apache Polaris
> podling
> > !
> >
Hi JB,
The right URL with the release tarball is:
https://dist.apache.org/repos/dist/dev/incubator/polaris/0.10.0-beta-incubating/
With that URL:
+1 (non-binding)
- Verified checksums and signatures
- Verified the source distribution has no binary file
- Verified "gradlew rat test" pa
preference would be to make this
> an immutable class that has the principal entity and all active principal
> roles all in the constructor.
>
> Mike
>
> On Sun, Apr 20, 2025 at 8:34 AM Alex Dutra
> wrote:
>
> > Hi Mike,
> >
> > I am generally fine with th
; simplify current JDBC PRs too.
> > > > > >
> > > > > > We can certainly add capabilities later, because having realm ID
> in
> > > the
> > > > > PR
> > > > > > does not preclude other deployment choices.
> > &
Hi Mike,
I am generally fine with the spec changes.
I have however some concerns around the way we handle principal roles today
in Polaris, and as I was preparing the PR with support for external IDPs
[1], some oddities stood out:
1. The pseudo-role PRINCIPAL_ROLE:ALL seems, by convention, to
nks for the extra flexibility. Looking forward to the PR
>
> Mike
>
> On Wed, Apr 16, 2025 at 12:54 PM Alex Dutra >
> wrote:
>
> > Hi again,
> >
> > As a follow-up, I was able today to make it possible for each realm to be
> > dynamically authenticated by
On Apr 18, 2025, at 3:14 AM, Jean-Baptiste Onofré
> wrote:
> >
> > I can update my PR with docker image pub ;)
> >
> > Le ven. 18 avr. 2025 à 12:12, Jean-Baptiste Onofré a
> > écrit :
> >
> > That’s a good idea.
> >
> > I would prefer a nightl
Hi JB,
In my opinion, it makes sense to include the eclipselink module by default,
in all distributions. Without eclipselink, the distributables are pretty
much useless for anything else than prototyping or evaluating.
By the way, for the admin tool, it really doesn't make any sense to ship it
wi
Hi JB,
Thanks for driving this!
Would it make sense to also publish nightly docker images, with a tag like
"unstable" or a timestamp?
Thanks,
Alex
On Wed, Apr 16, 2025 at 5:13 PM Russell Spitzer
wrote:
> Great news!
>
> On Wed, Apr 16, 2025 at 10:04 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi
this extra flexibility will make it easier for you to adapt to
Quarkus OIDC.
Thanks,
Alex
Alex
On Wed, Apr 16, 2025 at 3:26 PM Alex Dutra wrote:
> Hi Mike,
>
> My current work makes it possible to define if the authentication is
> *internal* (using the internal token endpoint +
need to ensure is that we can
> support both external identity providers as well as the internal token
> broker.
>
> Mike
>
>
> On Tue, Apr 15, 2025 at 6:52 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi Alex,
> >
> > It sounds like a good plan :)
> >
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
;
> 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
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 proper Quarkus Security mechanisms.
In parallel to that, support for external identity providers has been
requested many times
Congratulations to you all, very well deserved!!
Alex
Le jeu. 27 mars 2025 à 06:45, Jean-Baptiste Onofré a
écrit :
> Congrats !
>
> Regards
> JB
>
> Le mer. 26 mars 2025 à 22:47, Russell Spitzer
> a
> écrit :
>
> > Hi y'all!
> >
> > I'm excited to let the Polaris Community know that the PPMC h
Hi JB,
That's a very good idea.
Regarding Docker images, I think it would be great if users could just
"docker pull apache/polaris" and start using Polaris, as opposed to having
to manually build the images.
However, a Docker image with just in-memory persistence is likely useless
for anything e
;
> Cheers,
> Dmitri.
>
> On Fri, Mar 14, 2025 at 4:37 PM Alex Dutra
> wrote:
>
> > Hi JB,
> >
> > That's a very good idea.
> >
> > Regarding Docker images, I think it would be great if users could just
> > "docker pull apac
+0 as well, I am not bothered by Renovate at all personally.
On Fri, Feb 21, 2025 at 6:16 PM Dmitri Bourlatchkov
wrote:
> +0 -- Renovate "noise" does not bother me personally, but I'm ok with less
> frequent updates.
>
> Cheers,
> Dmitri.
>
> On Fri, Feb 21, 2025 at 8:41 AM Jean-Baptiste Onofré
hers think about this topic as well.
Thanks,
Alex
On Fri, Jan 31, 2025 at 10:42 AM Alex Dutra wrote:
> Hi,
>
> Let me try to shed some context. Helm chart versioning was designed to be
> independent of application versioning. This is why the Chart.yaml
> descriptor provides two
Hi,
Let me try to shed some context. Helm chart versioning was designed to be
independent of application versioning. This is why the Chart.yaml
descriptor provides two fields:
- "version" is the Helm chart version, and follows semver strictly
- "appVersion" is the target application version
xisting realm-resolution
> > >>> mechanisms.
> > >>>
> > >>> As mentioned in my previous post, I'm concerned about custom code
> that
> > >>> extends a Polaris interface. That approach requires to hook into all
> > >>> ex
Hi all,
I guess we need to align our vision of what "RealmId" (or whatever we call
it eventually) actually represents.
Some of us seem to consider that this component is really just the unique
identifier of a realm entity, pretty much like a primary key. Under that
vision, the component is not ex
Hi Yufei,
Thanks for opening this discussion, I agree that we could improve the
naming.
I have a slight preference for Option 1, first because it's more
extensible: realms could maybe require more properties one day, e.g. a
state (initializing/active/inactive/deleted). But also because using
stri
Hi Dmitri,
I think it would make sense to remove these annotations. While convenient,
such annotations freeze the allowed roles at compile time, and imho this
won't be extensible enough for Polaris.
Thanks,
Alex
On Fri, Jan 24, 2025 at 3:25 PM Dmitri Bourlatchkov
wrote:
> Hi All,
>
> Currently
CENSE/NOTICE for this distribution).
>
> Thanks !
> Regards
> JB
>
>
> On Tue, Jan 14, 2025 at 3:18 PM Alex Dutra
> wrote:
> >
> > Hi all,
> >
> > As mentioned already in another email earlier today, we still have a few
> > PRs to merge to ful
Hi all,
I think we also need to discuss how PRs are reviewed, approved or rejected.
I just read the CONTRIBUTING.md file, and it doesn't say much about it.
What I think is paramount here is: *assume good intentions*. No one is here
to make your life harder, or to introduce malicious code. We are
Hi,
If there are issues incorrectly labeled as bugs, that's maybe also because
we don't give many choices to users; when opening an issue, our templates
are very opinionated and only offer 3 options: "Bug report", "Feature
request", and "Report a security vulnerability" (with too many fields to
fi
sent time while we are trying to
> > improve the persistence interface(s).
> >
> > Also, on a more practical level, the in-memory metastore is quite useful
> > for testing and development.
> >
> > On Tue, Jan 14, 2025 at 9:28 AM Jean-Baptiste Onofré
>
Hi all,
I think Dmitri's suggestion makes sense as a short-term solution. Removing
EclipseLink is a much bigger task, and I don't think we'll have time to do
that before the 1.0.0 release. Imho the 1.0.0 release will ship with
Quarkus + EclipseLink.
Thanks,
Alex
On Tue, Jan 14, 2025 at 4:25 PM J
Hi all,
As mentioned already in another email earlier today, we still have a few
PRs to merge to fully achieve the transition to Quarkus.
The first one is the Docker PR: https://github.com/apache/polaris/pull/610
Since it's an important topic, I would like to summarize the most important
changes
. As we
> are not in the rush about rc2 (we agreed to do rc2 in the coming
> weeks).
>
> Let's just give the time to the community to be back from "festive break".
>
> Regards
> JB
>
> On Tue, Dec 31, 2024 at 2:32 PM Alex Dutra
> wrote:
> >
>
Congrats Dennis, and welcome aboard!
Alex
On Mon, Jan 13, 2025 at 9:35 AM Robert Stupp wrote:
>
> Welcome Dennis!
>
> On 13.01.25 08:38, Jean-Baptiste Onofré wrote:
> > Hi folks,
> >
> >
> > We are very happy to announce Dennis Huo as new Apache Polaris
> > (incubating) podling committer !
> >
>
Hi Dennis,
Thanks for starting this discussion!
The proposed time slot is generally OK for me, but what weekday do you
have in mind? I wouldn't be able to attend on some weekdays.
Other than that, I was wondering how much of the Catalog Federation
work would have to be built on top of a yet-to-b
+1 (nb)
Verified signatures, checksums, licenses. Checked that no binary files
were present. Building the sources with Gradle works.
Alex
On Wed, Jan 8, 2025 at 5:01 PM Jean-Baptiste Onofré wrote:
>
> Hi folks,
>
> As mentioned in another thread, I submit Apache Polaris
> 0.9.0-incubating rc2 t
Hi all,
That's great news, congratulations Dmitri and welcome to the team!
Thanks,
Alex
On Tue, Jan 7, 2025 at 7:30 PM Robert Stupp wrote:
>
> Hi folks,
>
> We are very happy to announce a new committer to the Apache Polaris
> (incubating) podling !
>
> Welcome Dmitri Bourlatchkov (dimas-b) !
p wrote:
>
> > Thanks Alex!
> >
> > I agree and I think we should move forward and merge the Quarkus PR.
> >
> > Robert
> >
> >
> > On 31.12.24 14:32, Alex Dutra wrote:
> > > Hi all,
> > >
> > > I hope everyone is having
Hi all,
I hope everyone is having a great holiday season so far!
Unless I'm mistaken, I think we have an agreement to move forward with the
switch to Quarkus. I'm wondering when we should merge it? Keeping such a large
PR open for too long is not ideal, but I also don't want to rush it.
Here 's
Hi all,
FYI I opened a PR with a fix for #542:
https://github.com/apache/polaris/pull/593
Thanks,
Alex
On Fri, Dec 20, 2024 at 6:09 AM Jean-Baptiste Onofré
wrote:
> Hi Yufei
>
> Yes there is still one issue I’m working on (about the binary
> distribution).
>
> We discussed rc2 with some comm
Hi JB,
That’s an excellent idea! Thanks for driving this. If possible, I would
like to be an administrator of the Docker repository.
Thanks,
Alex
Le mer. 18 déc. 2024 à 19:21, Yufei Gu a écrit :
> It's great to have a docker image that users can download and try it
> immediately! Thanks for d
'm not saying that this
> > > isn't possible, only that it requires some work from users. In Nessie,
> we
> > > do this e.g. to allow users to provide a subscriber for Nessie events.
> > >
> >
> > It's a choice though? For example if the application would us
Hi Andrew,
I think the idea of extending / augmenting Polaris behavior is very
appealing, but deserves some more thinking.
First off, I'm a bit concerned that this event listener interface would end
up with dozens, maybe hundreds of rather unrelated methods: "onFooStarted",
"onBarDropped", etc.
Hi,
Maven versioning only partially adheres to semver:
https://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
Regarding the -SNAPSHOT token, the docs do not mention the case when the
qualifier is -SNAPSHOT but I believe it’s expanded just the
same. However the .S
Hi all,
+1 (nb), but with some caveats: I tested signatures, checksums, and ran
tests and license checks. All OK.
But I found some non-empty binary files:
> find . -type f ! -size 0 | perl -lne 'print if -B'
./site/static/favicons/favicon.ico
./site/static/favicons/android-chrome-192x192.png
./s
and polaris-service-quarkus, for three
> > reasons:
> > - it doesn't bring any benefits for the users, only confusion (which
> > service should I use)
> > - it will be almost impossible to maintain (in sync)
> > - it will prevent to leverage extensions provided (especiall
Hi Michael, hi all,
I had a look at your branch and am very pleased to see that it was
relatively easy to get DI working with DW + HK2. Good news!
Digging a bit into the details, I see that most beans are annotated with
@Named now. This is probably OK for Quarkus too, although there are other
tec
+1, I left one minor comment but otherwise the bylaws look good to me.
Thanks,
Alex
On Tue, Sep 3, 2024 at 8:25 PM Dmitri Bourlatchkov
wrote:
> Thanks for writing these guidelines, Robert! They look pretty reasonable to
> me.
>
> Cheers,
> Dmitri.
>
> On Mon, Sep 2, 2024 at 5:06 AM Robert Stupp
78 matches
Mail list logo
