Re: [VOTE] Release Apache Iceberg 1.8.1 RC1

need to make > the change to get the token from the headers of DefaultAuthSession. > > With that, +1 (non-binding) > > Thanks, > Aihua > > > > On Thu, Feb 27, 2025 at 9:26 AM Alex Dutra > wrote: > >> Hi Aihua Xu, >> >> I reviewed your PR but withou

Re: [VOTE] Release Apache Iceberg 1.8.1 RC1

eaders, > OAuth2Util.authHeaders(authResponse.token())); > config = fetchConfig(initClient, authHeaders, props); > } else { > authResponse = null; > Map authHeaders = > RESTUtil.merge(initHeaders, OAuth2Util.authHeaders(initToken)); > config = fetchConfig(initCli

Re: [VOTE] Release Apache Iceberg 1.8.1 RC1

Hi Aihua, I just tested 1.8.1 with Polaris OSS and I am not seeing anything different. Can you share your setup? Below is my Spark setup. Thanks, Alex ./gradlew run token=$(curl -s http://localhost:8181/api/catalog/v1/oauth/tokens \ --user root: \ -d grant_type=client_credentials \ -d s

Re: [DISCUSS] Rest Catalog 419 Response Code

n't rely solely on it for token expiration. > > > > However, the current REST spec doesn't clarify this. We should make it > more explicit. > > > > We could try to deprecate it later if needed. > > > > Yufei > > > > > > On Fri, Feb

Re: [DISCUSS] Rest Catalog 419 Response Code

Hi all, I think there are two aspects in this issue that should be discussed separately: 1. What are the pros and cons of having a custom HTTP response code for authentication issues, as opposed to using 401? 2. How should clients deal with authentication issues, both 401 and 419? *Rega

Re: [VOTE] Deprecate IRC snapshot-id Field of SetStatisticsUpdate

+1 (nb) On Tue, Jan 21, 2025 at 11:30 AM Piotr Findeisen wrote: > +1 non-binding > > On Tue, 21 Jan 2025 at 10:25, Fokko Driesprong wrote: > >> +1 >> >> Thanks for cleaning this up Christian! >> >> Kind regards, >> Fokko >> >> Op di 21 jan 2025 om 08:25 schreef Christian Thiel < >> christian.t.

[DISCUSS] Auth Manager API – remaining tasks

Hi all, As you know, the original Auth Manager PR [1] has been closed because it was deemed too big for review. The reviewers, after 4 months, requested to split the PR into smaller PRs and merge them one by one. I am planning six PRs in total: * Auth Manager API part 1: HTTPRequest, HTTPHeader

Re: New committer: Matt Topol

Congratulations, Matt! Go!! On Tue, Dec 10, 2024 at 1:08 PM Péter Váry wrote: > Congratulations Matt! > > On Tue, Dec 10, 2024, 12:58 Ian Cook wrote: > >> Congratulations Matt!!! >> >> On Tue, Dec 10, 2024 at 05:28 Fokko Driesprong wrote: >> >>> Hey everyone, >>> >>> The Project Management Com

Re: [VOTE][Go] Release Apache Iceberg Go v0.1.0 RC2

Hi, +1 (non-binding) I verified: * checksums: OK * signature: OK * LICENSE and NOTICE: OK * manually checked no binaries present: OK * checked ASF headers, using the included dev/check-license script: OK * checked build with go test ./... and go build ./...: OK Also tested the iceberg binary ag

Re: [PROPOSAL] Refactore use of Guava Lists.*

Hi all, But aren't we now building on Java 11+? I think we could go one step ahead and replace most of these Guava factory methods by List.of(), List.copyOf() and the like – as long as the collection is not modified after. It's more concise and saves us a Guava import. Thanks, Alex On Thu, Oct

Re: [ANNOUNCE] Welcoming new committers and PMC members

Congratulations to you all! Thanks, Alex On Tue, Jul 23, 2024 at 5:30 PM Jack Ye wrote: > Congratulations!! > > Best, > Jack Ye > > On Tue, Jul 23, 2024 at 8:16 AM Ryan Blue > wrote: > >> Congratulations, everyone! And thanks for all your contributions! >> >> On Tue, Jul 23, 2024 at 8:06 AM Me

Re: [DISCUSS] Formalized File IO Properties

Hi, Also +1 on standardizing properties. I'm looking forward to this discussion topic. In particular, REST catalog properties imho should be standardized with the "rest." prefix, and REST auth properties should imho have a prefix like "rest.auth..", e.g. "rest.auth.oauth2.issuer-url". Thanks, Ale

Re: [Vote] Deprecate oauth tokens endpoint

+1 (nb) I think this PR is a good addition and sets a solid ground for future improvements, the first of which being the AuthManager interface[1]. Thanks, Alex Dutra [1]: https://github.com/apache/iceberg/pull/10621 On Tue, Jul 9, 2024 at 12:55 PM Ajantha Bhat wrote: > +1 (non-binding)

Re: [DISCUSS] Describing REST Server capabilities

Hi all, So far we've been thinking of capabilities as equivalent to a set of endpoints. That's a rather technical definition. It also brings one important limitation: one endpoint can only be "governed" by one capability. Granted, most capabilities do require implementing specific endpoints. But

Re: [INFO] Preparing the Apache Iceberg 1.6.0 release

Hi JB, Thank you for putting up the 1.6 release proposal. I also would like to bump the Nessie version to its next release, which is due today and should be available in a few hours from now. My understanding is that the Renovate bot would immediately pick up the new version and automatically cre

Re: Addressing security questions in the Iceberg REST specification

start another email thread to discuss these practicalities, but let's first reach consensus on the broader security issues voiced here, before we tackle the details. Thanks, Alex Dutra On Tue, May 28, 2024 at 8:41 PM Amogh Jahagirdar wrote: > I disagree with removing "/v1/oauth/tok