For the token endpoint, I recommend we stay consistent with the Iceberg
REST spec by marking it as deprecated and aligning its removal with the
same timeline as outlined in the Iceberg spec. Here are a few key points to
consider:
1. Since the endpoint is marked as deprecated, and most production
e
> If we remove the endpoint in Polaris, clients prior to that release will
have no mechanism for generating a token.
Missed to address this in my previous reply :)
Existing Java REST Catalog clients (based on Iceberg's impl.) will be able
to use bearer tokens and the Client Credentials OAuth2 Flo
> If we remove the endpoint in Polaris, clients prior to that release will
have no mechanism for generating a token.
The basic problem is that producing an auth token from the /token endpoint
in Polaris makes it assume the role of the Authorization Server according
to the OAth2 RFC [2].
Moreover,
That’s a good point.
I think we can keep the endpoint for 1.0 but already flag as deprecated.
Thoughts ?
Regards
JB
Le lun. 23 sept. 2024 à 21:05, Michael Collado a
écrit :
> +1 on Russell’s comment.
>
> Re: the OAuth endpoint, it seems to me that compatibility with Iceberg
> clients needs to
If we use 1.0-incubating it’s fine.
Ok for that :)
Regards
JB
Le lun. 23 sept. 2024 à 20:53, Russell Spitzer
a écrit :
> My only minor feedback is I'd prefer we do a first release as 1.0. I think
> there is an allergy to 0.1 software in production so I'd rather we just
> start at 1.
>
> On Mon
+1 on Russell’s comment.
Re: the OAuth endpoint, it seems to me that compatibility with Iceberg
clients needs to be considered. I think that prior to Iceberg 1.5 or so,
there was not support for an external oauth tokens endpoint. If we remove
the endpoint in Polaris, clients prior to that release
Good point, Russell! Starting with 1.0 makes sense to me.
Cheers,
Dmitri.
On Mon, Sep 23, 2024 at 2:54 PM Russell Spitzer
wrote:
> My only minor feedback is I'd prefer we do a first release as 1.0. I think
> there is an allergy to 0.1 software in production so I'd rather we just
> start at 1.
>
My only minor feedback is I'd prefer we do a first release as 1.0. I think
there is an allergy to 0.1 software in production so I'd rather we just
start at 1.
On Mon, Sep 23, 2024 at 1:50 PM Jean-Baptiste Onofré
wrote:
> Hi Dmitri
>
> It makes sense to me.
>
> Regards
> JB
>
> Le lun. 23 sept. 2
Hi Dmitri
It makes sense to me.
Regards
JB
Le lun. 23 sept. 2024 à 20:01, Dmitri Bourlatchkov
a écrit :
> From my POV, I'd propose to resolve the OAuth token endpoint concern [1]
> before the initial release.
>
> I guess it might be a rather big refactoring, but this issue is already
> general
>From my POV, I'd propose to resolve the OAuth token endpoint concern [1]
before the initial release.
I guess it might be a rather big refactoring, but this issue is already
generally accepted as a security concern in the Iceberg community, so I
think it would be preferable to resolve it before th
Hi folks,
As we know from experience, that the first release needs some careful
preparation steps, I would like to propose aiming for the Apache
Polaris release by the end of October (after CoC NA).
I propose to start from 0.1-incubating (currently we are building
999-SNAPSHOT :) ).
I already cre
+1 to community sync-up every two weeks.
Yufei
On Fri, Sep 20, 2024 at 8:46 AM Aniket Kulkarni
wrote:
> On Fri, Sep 20, 2024 at 05:08:35PM UTC, Jean-Baptiste Onofré wrote:
> > 2. After CommunityOverCode, what about having a community meeting
> > every two weeks (at 6pm CEST) ? The purpose is t
Awesome, thanks John !
Regards
JB
On Mon, Sep 23, 2024 at 3:05 PM John Roesler wrote:
>
> Thanks for tackling that, JB!
>
> I approved the PR.
> -John
>
> On Mon, Sep 23, 2024, at 03:47, Jean-Baptiste Onofré wrote:
> > Hi folks,
> >
> > I deployed a new website version including the last merges.
Thanks for tackling that, JB!
I approved the PR.
-John
On Mon, Sep 23, 2024, at 03:47, Jean-Baptiste Onofré wrote:
> Hi folks,
>
> I deployed a new website version including the last merges.
>
> I also created a PR with GitHub Actions for:
> - test website changes (ci)
> - automatically deploy we
Hi folks,
I deployed a new website version including the last merges.
I also created a PR with GitHub Actions for:
- test website changes (ci)
- automatically deploy website when a merge is done on the main branch (deploy)
Here's the PR: https://github.com/apache/polaris-site/pull/6
Regards
JB
15 matches
Mail list logo
