Given that the boundary between credentials and other storage configs is not clear, I am not convinced that we need both "config" and "storage-credentials". It might be simpler to keep only one field. However, neither name fully captures the combined intent. We could introduce a new field such as storage-config/storage-access-config, but that creates another problem: consolidating two fields by adding a new one effectively leaves us with three fields :-). Jokes aside. In reality, there are two possible options: 1. Just use "storage-credentials" and deprecate "config" 2. Create a new field named "storage-config" and deprecate the other two.
Yufei On Mon, Mar 2, 2026 at 2:57 AM Alexandre Dutra <[email protected]> wrote: > Hi Yun, > > > This means there is currently some overlap between the config and > storage-credentials fields. Is my understanding correct? > > That is my understanding too, and this will be the case until we > consider that we can drop support for credentials in config for old > clients. > > Thanks, > Alex > > On Sat, Feb 28, 2026 at 12:27 AM yun zou <[email protected]> > wrote: > > > > Hi Eduard and Alexandre, > > > > Thank you both for chiming in on this — I really appreciate the > clarification. > > > > If I understand correctly, the storage-credentials field contains only > > credential-related configurations and was introduced mainly for the > > following reasons: > > > > There was a lack of clear documentation around credential-related > > entries within the existing config field in the LoadTable response. > > > > It is used by the credential endpoint to support credential refresh. > > > > As Alexandre mentioned, all credential configurations are still > > included in the config field of LoadTableResult for backward > > compatibility. This means there is currently some overlap between the > > config and storage-credentials fields. Is my understanding correct? > > > > Best regards, > > Yun > > > > On Fri, Feb 27, 2026 at 5:40 AM Alexandre Dutra <[email protected]> > wrote: > > > > > > Hi Yun, > > > > > > In addition to what Eduard said, I would like to stress this sentence > > > from the design doc: "In order to maintain backward compatibility with > > > older clients, credentials still need to be passed as properties via > > > the config field for LoadTableResult and LoadViewResult." > > > > > > IOW, servers must send credentials in both places: config and > > > storage-credentials, to stay compatible with older clients; this is > > > what Apache Polaris does [1]. > > > > > > Thanks, > > > Alex > > > > > > [1]: > https://github.com/apache/polaris/blob/579b271b8c41cd26339bccfd771c1a591ad27039/runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalogHandler.java#L856-L861 > > > > > > On Fri, Feb 27, 2026 at 7:52 AM Eduard Tudenhöfner > > > <[email protected]> wrote: > > > >> > > > >> 1) What is the intended boundary between storage-credentials and > > > >> config in LoadTableResult? > > > > > > > > > > > > We used to send back all sorts of configurations in the config of a > LoadTableResponse (examples are shown here) but those configurations > weren't well documented for different storage providers. Later we > introduced the concept of storage credentials which are sent back in the > storage-credentials field. Those will only contain storage credentials, > such as access-key-id / secret-access-key / session-token / > session-token-expires-at-ms in the case of S3 and no other configurations. > Also the storage-credentials field takes precedence over whatever is sent > in the config. > > > > > > > > > > > >> 2) What is the motivation behind this design choice? > > > > > > > > > > > > Storage credentials offer more flexibility because they let you use > different credentials for different storage prefixes. Additionally, those > credentials are being refreshed automatically, which is not the case with > the vended credentials that are sent as part of the config. > > > > > > > > Here's the original design that outlines why we standardized > credentials into the storage-credentials field. > > > > > > > > > > > > On Thu, Feb 26, 2026 at 9:22 PM yun zou <[email protected]> > wrote: > > > >> > > > >> Hi All, > > > >> > > > >> I’m looking into the credential vending support for Iceberg and got > a > > > >> bit confused about the config and storage-credentials fields in > > > >> LoadTableResult. > > > >> > > > >> From what I understand: > > > >> > > > >> storage-credentials can contain configurations that are not strictly > > > >> credential-related, such as client.region. > > > >> > > > >> The description for "config" states that it is "table-specific > > > >> configuration for the table's resources, including its HTTP client > and > > > >> FileIO. For example, config may contain a specific FileIO > > > >> implementation class for the table depending on its underlying > > > >> storage." > > > >> > > > >> In our current implementation, we kind of merge both fields when > > > >> initializing the client, which makes me wonder: > > > >> > > > >> 1) What is the intended boundary between storage-credentials and > > > >> config in LoadTableResult? > > > >> > > > >> 2) What is the motivation behind this design choice? > > > >> > > > >> Thanks in advance for clarifying! > > > >> > > > >> Best regards, > > > >> Yun >
