Thanks for the reply Eduard! I think it is fine to defer fine-tuning credential refreshes to a later PR.
I'm upgrading my vote to +1 (non-binding). Cheers, Dmitri. On Tue, Oct 22, 2024 at 11:11 AM Eduard Tudenhöfner < etudenhoef...@apache.org> wrote: > Hey Dmitri, > > the idea behind the endpoint itself is really just to provide *valid* > credentials for a given table when a client asks for them. > If the server returned you two S3 credentials, the client will use the one > with the longest prefix and if that credential expires, it will ask the > server again for *valid* credentials. > That means the server can again return you two S3 credentials, even if > that second unused credential from the previous endpoint call didn't expire > yet. > I don't think we'd want to complicate the endpoint *at this point* to > have a differentiation between what specific credentials a client wants to > receive from the server. > > Thanks, > Eduard > > On Mon, Oct 21, 2024 at 6:36 PM Dmitri Bourlatchkov > <dmitri.bourlatch...@dremio.com.invalid> wrote: > >> -0 (non-binding) >> >> If multiple credentials are vended for a table (which is allowed) the >> current API requires all credentials to be refreshed, when any of the >> previous credentials expires. I think this is suboptimal (but can probably >> be made to work in most practical cases). >> >> Cheers, >> Dmitri. >> >> On Mon, Oct 21, 2024 at 6:07 AM Eduard Tudenhöfner < >> etudenhoef...@apache.org> wrote: >> >>> Hey everyone, >>> >>> I'd like to vote on #11281 >>> <https://github.com/apache/iceberg/pull/11281>, which introduces a new >>> endpoint and allows retrieving/refreshing vended credentials for a given >>> table. >>> >>> Please vote +1 if you generally agree with the path forward. >>> >>> Please vote in the next 72 hours >>> >>> [ ] +1, commit the proposed spec changes >>> [ ] -0 >>> [ ] -1, do not make these changes because . . . >>> >>> >>> Thanks everyone, >>> >>> Eduard >>> >>
