Hi all, The vote on the spec changes has finally passed and the sepc changes are merged! Many thanks to all the voters and reviewers.
If you are interested, please now review the related Java code changes: https://github.com/apache/iceberg/pull/15451 Thanks, Alex On Mon, Mar 2, 2026 at 12:11 PM Alexandre Dutra <[email protected]> wrote: > > 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
