Hi all, AFAIK the current Polaris code appears to resolve the storage configuration from the leaf (table), upwards via the namespace elements to the catalog, choosing the first one found. I am not sure whether that functionality is already used anywhere? Being able to use a storage configuration on a namespace or a leaf appears appealing.
OTOH I see a demand for named storage configurations. I wonder whether the mechanism to derive the storage configuration could support both "directly attached" and "referenced" storage configurations: A namespace element or leaf can have either a "directly attached" storage configuration or a reference to a named one. We'd need management-ish APIs to handle the storage configurations for a namespace or leaf. These APIs, which do not exist yet, could start with "directly attached" storage configurations and once the authz questions are resolved, extend to include named, shared storage configurations. Thoughts? Robert On Thu, Jun 11, 2026 at 7:28 PM Dmitri Bourlatchkov <[email protected]> wrote: > 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? > >> > > >
