Hi all, The spec changes PR has received 4 approvals. I will start another VOTE thread shortly.
Thanks, Alex On Thu, Feb 26, 2026 at 3:06 PM Alexandre Dutra <[email protected]> wrote: > > Hi all, > > In yesterday's catalog sync, we decided to split the current PR in > two, one for spec changes, the other for code changes. > > Here they are: > > - Spec changes: https://github.com/apache/iceberg/pull/15450 > - Code changes: https://github.com/apache/iceberg/pull/15451 > > The ongoing vote has therefore been cancelled – apologies for the > inconvenience. > > Once reviewed and approved, #15450 will be submitted to a new vote. > > Thanks, > Alex > > On Mon, Feb 23, 2026 at 10:13 AM Alexandre Dutra <[email protected]> wrote: > > > > Hi Yufei, > > > > OK, I will start the VOTE thread shortly. Stay tuned! > > > > Thanks, > > Alex > > > > On Fri, Feb 20, 2026 at 8:44 PM Yufei Gu <[email protected]> wrote: > > > > > > Thanks a lot for working on it, Alex. I think it's ready to open a vote. > > > Yufei > > > > > > > > > On Thu, Feb 19, 2026 at 4:47 AM Alexandre Dutra <[email protected]> wrote: > > >> > > >> Hi all, > > >> > > >> The PR to promote the signer endpoint to the main specification has > > >> now received 3 approvals [1]. A big thank you to Eduard, Prashant and > > >> Steve for their thorough reviews! > > >> > > >> With these approvals in hand, is this the right time to start a VOTE > > >> thread, or should we wait a bit longer to gather more input and > > >> reviews? > > >> > > >> Thanks, > > >> Alex > > >> > > >> [1]: https://github.com/apache/iceberg/pull/15112 > > >> > > >> On Thu, Jan 22, 2026 at 5:26 PM Alexandre Dutra <[email protected]> > > >> wrote: > > >> > > > >> > Hi all, > > >> > > > >> > The PR is up for review: > > >> > > > >> > https://github.com/apache/iceberg/pull/15112 > > >> > > > >> > Thanks, > > >> > Alex > > >> > > > >> > > > >> > On Wed, Jan 21, 2026 at 6:49 PM Ryan Blue <[email protected]> wrote: > > >> > > > > >> > > A VOTE for REST spec updates usually happens after the changes are > > >> > > available to review. > > >> > > > > >> > > On Wed, Jan 21, 2026 at 9:39 AM Alexandre Dutra <[email protected]> > > >> > > wrote: > > >> > >> > > >> > >> Thank you all! > > >> > >> > > >> > >> I think we have an agreement here. I'm happy to start working on the > > >> > >> PR, but I recall that a VOTE thread is necessary for this type of > > >> > >> modification. Should we initiate the vote now, or wait until the PR > > >> > >> is > > >> > >> ready for merging (and vote on the PR contents)? > > >> > >> > > >> > >> Thanks, > > >> > >> Alex > > >> > >> > > >> > >> On Wed, Jan 21, 2026 at 1:08 AM Yufei Gu <[email protected]> > > >> > >> wrote: > > >> > >> > > > >> > >> > +1 from me. > > >> > >> > Promoting the signer endpoint to the table level makes it more > > >> > >> > consistent with other table scoped APIs, and it cleanly provides > > >> > >> > the catalog(warehouse), namespace and table context without > > >> > >> > relying on provider specific properties. > > >> > >> > > > >> > >> > Yufei > > >> > >> > > > >> > >> > > > >> > >> > On Tue, Jan 20, 2026 at 12:08 PM Christian Thiel > > >> > >> > <[email protected]> wrote: > > >> > >> >> > > >> > >> >> +1 from me too, thanks Alex! > > >> > >> >> I tested returning the new Endpoint as the `s3.signer.endpoint` > > >> > >> >> config of a LoadTableResult against all Iceberg Releases from > > >> > >> >> 1.6.1 with Spark as well as pyiceberg 0.9 and 0.10 without > > >> > >> >> problems. As long as the behaviour of the Endpoint stays the > > >> > >> >> same for S3, I don't see any issues. > > >> > >> >> > > >> > >> >> On Tue, 20 Jan 2026 at 18:43, Jean-Baptiste Onofré > > >> > >> >> <[email protected]> wrote: > > >> > >> >>> > > >> > >> >>> +1 > > >> > >> >>> > > >> > >> >>> Regards > > >> > >> >>> JB > > >> > >> >>> > > >> > >> >>> On Fri, Jan 16, 2026 at 3:29 PM Alexandre Dutra > > >> > >> >>> <[email protected]> wrote: > > >> > >> >>>> > > >> > >> >>>> Hi all, > > >> > >> >>>> > > >> > >> >>>> We discussed remote signing last Wednesday during the catalog > > >> > >> >>>> sync > > >> > >> >>>> meeting and we all agreed that the default signing endpoint > > >> > >> >>>> [1] is too > > >> > >> >>>> rigid. It lacks information about the table and namespace, but > > >> > >> >>>> is also > > >> > >> >>>> unaware of catalogs/warehouses, which can be challenging when > > >> > >> >>>> the same > > >> > >> >>>> signer client has to access multiple catalogs. > > >> > >> >>>> > > >> > >> >>>> One of the ideas that emerged was to promote the signer > > >> > >> >>>> endpoint to > > >> > >> >>>> the "top-level" spec, under the table path. In short, it would > > >> > >> >>>> become > > >> > >> >>>> something like this: > > >> > >> >>>> > > >> > >> >>>> /v1/{prefix}/namespaces/{namespace}/tables/{table}/sign > > >> > >> >>>> > > >> > >> >>>> Promoting the endpoint makes it more aligned with similar > > >> > >> >>>> ones, like > > >> > >> >>>> the table credentials endpoint. It also solves the problem of > > >> > >> >>>> passing > > >> > >> >>>> the namespace, table and warehouse identifiers to the server. > > >> > >> >>>> > > >> > >> >>>> The endpoint would become provider-agnostic though. The current > > >> > >> >>>> endpoint structure appears to be sufficiently generic, showing > > >> > >> >>>> no > > >> > >> >>>> S3-specific quirks. For example, implementing Azure support > > >> > >> >>>> using SAS > > >> > >> >>>> tokens seems feasible at first glance without any apparent > > >> > >> >>>> obstacles > > >> > >> >>>> (that I could think of). But there might be implications that > > >> > >> >>>> I'm not > > >> > >> >>>> immediately seeing. > > >> > >> >>>> > > >> > >> >>>> Of course, we would need to migrate the existing table > > >> > >> >>>> properties to > > >> > >> >>>> more neutral names, e.g.: > > >> > >> >>>> > > >> > >> >>>> s3.signer.uri -> signer.uri > > >> > >> >>>> s3.signer.endpoint -> signer.endpoint > > >> > >> >>>> > > >> > >> >>>> What are your thoughts on this idea? > > >> > >> >>>> > > >> > >> >>>> Thanks, > > >> > >> >>>> Alex > > >> > >> >>>> > > >> > >> >>>> [1]: > > >> > >> >>>> https://github.com/apache/iceberg/blob/55bfc7e82d03b5038bc5d0da852bd16615486926/aws/src/main/resources/s3-signer-open-api.yaml#L61
