Hi All, Good idea about splitting Management API grants into a new PR!
Cheers, Dmitri. On Fri, Sep 25, 2026 at 1:50 PM Yufei Gu <[email protected]> wrote: > Thanks for chiming in, Prithvi. BTW, if we consider the grant logic change > is ready to go, we can split out the spec change to speed up. > > Yufei > > > On Fri, Sep 25, 2026 at 10:47 AM Prithvi S <[email protected]> > wrote: > > > Hi Dmitri, > > > > Anand, great work here. Thank you! > > > > The grant change looks good to me. TABLE_READ_METRICS on the table, > > namespace, and catalog enums is what we need, and 110 is a free code. > > Reading reports is allowed by that grant, by TABLE_FULL_METADATA, or by > > CATALOG_MANAGE_CONTENT. Sending scan and commit reports stays on > > TABLE_READ_DATA and TABLE_WRITE_DATA. > > > > One thing on the Ranger service def: table-metrics-read is only implied > by > > table-metadata-full. catalog-content-manage already lists the other > > children of table-metadata-full, since Ranger only expands one level, but > > it doesn't list table-metrics-read. I think a content-admin policy would > > miss the query, while CATALOG_MANAGE_CONTENT allows it. Adding it there > > would line them up. I'd leave it off catalog-metadata-manage, same as the > > built-in authorizer. > > > > The other one is the empty result. NoOpMetricsQuery returns an empty page > > and the handler sends 200, but the spec and changelog still say 501. > > > > Other than that I'm inclined to merge. > > > > Cheers, > > Prithvi S > > > > On Fri, Sep 25, 2026 at 7:59 PM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > Hi All, > > > > > > Starting a new thread for [1] to increase visibility. This is related > to > > PR > > > [4115]. > > > > > > [1] https://lists.apache.org/thread/c5jq95qwzn5dtc103rzk457gr8r0d6zh > > > > > > [4115] https://github.com/apache/polaris/pull/4115 > > > > > > From my POV we're good to merge. > > > > > > Please respond if you have any concerns. > > > > > > Thanks, > > > Dmitri. > > > > > >
