Hi All, To recap the discussion from the Community Sync today: My understanding is that the consensus was:
* Defer AuthZ aspects for later discussion. * Allow multiple Storage Config objects per Catalog. If more than one Storage Config is present, they are to have different (within the catalog) names. Rishi to open a new PR for this (scoped to REST API + Sever changes). * Defer CLI changes until we have the full end-to-end system working (it should be usable via curl) * PR 4023 is on hold for now. It is to be rebased after adding support for multiple Storage Configs * The connection between storage names and storage access credentials is to remain unchanged for now. It is effectively a deployment time concern given the current OSS code. Please correct / add if I missed anything. >From my POV, I think we still need to discuss how exactly entities (tables, views) will link to Storage Config before we can resume PR 4023. I propose storing the config name in the Entity properties (not in Table Metadata properties). If clients also need a way to define it while interacting with Polaris over the IRC API, let's discuss how that can be done. WDYT? Cheers, Dmitri. On Mon, Jun 8, 2026 at 2:17 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Srinivas, > > I see that PR 4023 is active again. I'll try and post a fresh review soon. > > Cheers, > Dmitri. > > On Thu, Mar 19, 2026 at 5:41 AM Srinivas Rishindra <[email protected]> > wrote: > >> Hi JB and Dmitri, >> >> I raised PR #4023 <https://github.com/apache/polaris/pull/4023> yesterday >> as part of the broader per-table storage config effort, and I believe it >> implements exactly what you are proposing. >> >> Building on the named storage configs introduced in PR #3409 >> <https://github.com/apache/polaris/pull/3409>, this PR allows namespaces >> and tables to specify a polaris.storage.name property. This acts as the >> "identifier" JB mentioned, allowing credential vending to resolve the >> correct, named storage config at runtime without introducing new >> management >> APIs. >> >> Could you please take a look at the PR and let me know if this aligns with >> what you are looking for? >> >
