>> I suppose this proposal is going to add a spec to Polaris docs or Open API yaml defining how the credential properties will need to be interpreted by clients.
Yes, I think we should add it to both the BOC and the OpenAPI description to improve visibility for users. >> I'd suggest not referencing Iceberg directly, but providing a native spec on the Polaris side to avoid confusion between Iceberg tables and Generic Tables . Sounds good to me. Jack @[email protected] <[email protected]> what do you think? Best Regards, Yun On Mon, Feb 9, 2026 at 12:03 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yun, > > I suppose this proposal is going to add a spec to Polaris docs or Open API > yaml defining how the credential properties will need to be interpreted by > clients. > > With such a spec clearly defining the config names for Polaris Generic > Tables, I do not see a problem with reusing the same property names as > existing Iceberg clients assume. I'd suggest not referencing Iceberg > directly, but providing a native spec on the Polaris side to avoid > confusion between Iceberg tables and Generic Tables (especially considering > that these config entries are not well-defined on the Iceberg side). > > Similarly, I suppose Polaris will provide Open API structures for the > objects representing vended credentials in its own spec. > > Does that sound reasonable? > > Thanks, > Dmitri. > > > > On Mon, Feb 9, 2026 at 1:18 PM yun zou <[email protected]> wrote: > > > Hi Dmitri and JB, > > > > Thanks a lot for the valuable feedback! > > > > > > >> How are clients supposed to know the meaning of credential properties > in > > the "config" section? > > > > This is a good point. Currently, the Iceberg specification does not > provide > > a clear definition of these configurations, and the existing > documentation > > may also be outdated. As Jack suggested, we can provide clear > documentation > > in Polaris to explain the built-in configuration support. Gravitino > follows > > a similar approach (see: > > https://gravitino.apache.org/docs/next/security/credential-vending). > > > > > > Regarding reusing the same StorageCredential definition as Iceberg, I do > > not see this as an antipattern. Generic Table represents a new set of > APIs > > compared to Iceberg and has the flexibility to evolve independently. > > However, reusing definitions for common concepts—such as namespaces and > > table identifiers—is reasonable. This helps maintain consistency within > > Polaris and lowers the adoption barrier for clients already familiar with > > Iceberg. > > > > > > For credential vending in particular, this concerns cloud storage > > credential configurations, which are fundamentally the same regardless of > > whether the table format is Iceberg or Generic Table. The existing > Iceberg > > StorageCredential definition is simple and sufficiently flexible to cover > > common scenarios, including S3 secret key credentials, S3 token > > credentials, ADLS token credentials, and others. It can also be easily > > extended to support new credential types introduced by cloud > > providers. Therefore, > > I believe it is reasonable and beneficial for Generic Table to adopt the > > same concept as Iceberg. > > > > > > Best Regards, > > > > Yun > > > > On Fri, Feb 6, 2026 at 11:50 PM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > Hi Yun > > > > > > At first glance, the proposal looks reasonable to me. It seems that a > > large > > > part of the "logic" is on the client side, interpreting the > > > storage-credentials properties. > > > That's OK for me because that's the purpose of Generic Table: a kind of > > > "storage" for other table formats (non Iceberg) where the clients have > to > > > "interpret". > > > > > > However, I'm a bit confused: the purpose of Generic Table is to support > > non > > > Iceberg table formats (as stated earlier). If we "couple" the Generic > > Table > > > with Iceberg, it looks anti-pattern and not aligned with the purpose of > > > Generic Table. I think it would be very confusing for Generic Table > > > "integrators" and "users" and create "dependencies" to Iceberg (if I > want > > > to use Delta or Hudi, I don't want to use Iceberg). > > > I would rather prefer to have something in the Generic Table "clients", > > not > > > coupled in any way with Iceberg. We can totally mimic the Iceberg logic > > in > > > Generic Table, but not "use" it. > > > > > > I will take a deeper look at the proposal. > > > > > > Regards > > > JB > > > > > > On Fri, Feb 6, 2026 at 7:29 PM yun zou <[email protected]> > > wrote: > > > > > > > Hi All, > > > > > > > > Generic Tables have been available since Polaris 1.0.0 and have seen > > > > growing interest from an increasing number of customers. > > > > > > > > However, the current Generic Table capability has some limitations. > One > > > > key gap is the lack of credential vending support. Without credential > > > > vending, query engines must access tables using long-lived, static > > cloud > > > > credentials configured directly in the engine runtime, which limits > > both > > > > usability and security. > > > > > > > > To address this, we propose adding credential vending support for > > Generic > > > > Tables. This enhancement would allow a Polaris catalog to dynamically > > > vend > > > > short-lived, scoped storage credentials to query engines at runtime > > when > > > > accessing Generic Tables. > > > > > > > > The goals of this proposal are to: > > > > > > > > 1. > > > > > > > > Enable credential vending support for Generic Tables in Polaris > > > > 2. > > > > > > > > Deliver an end-to-end experience for currently supported table > > > > formats, including Delta, Hudi, and Lance > > > > 3. > > > > > > > > Maintain consistency with the existing Iceberg credential vending > > > model > > > > > > > > Please find the attached short design document with additional > details. > > > We > > > > would appreciate your review and valuable feedback. > > > > > > > > link to google doc: > > > > > > > > > > https://docs.google.com/document/d/1QzTx4tcS23_mF-gc77GbTqtwuRHY5f_Aa_6E4VSKFU4/edit?tab=t.0#heading=h.rpqtaz73xt4v > > > > > > > > Best Regards, > > > > > > > > Yun > > > > > > > > > >
