+1 on revisiting the SPI discussion. I filed an issue for this: https://github.com/apache/polaris/issues/4004.
Yufei On Mon, Mar 16, 2026 at 5:37 AM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Travis, > > SPI discussions happened in the Community Sprint [1]... but I could not > find any related threads on dev. I guess we ought to revive that discussion > :) > > Cheers, > Dmitri. > > [1] > https://docs.google.com/document/d/1cUg4HnUGDN0JKMr0JWQTaKkgzSXENHZ4VMuyRfJ9oTQ/edit?tab=t.lzwxdgyu5e82#heading=h.5zojeahif6e > > On 2026/03/14 03:54:39 Travis Bowen wrote: > > Hi Dmitri, > > > > I agree with you here that it seems okay to remove these unused > operations based on Polaris not requesting them as well as the other > reasonings you mention about why they would be unlikely to be used in > implementations. > > > > I am glad you brought this to discuss and that EJ raised that they > affect the authorizer SPI. > > > > I think at this stage in Polaris while we need to be mindful of any SPI > changes we still have some flexibility. > > > > It would be nice to further formalize Polaris’s SPIs in the future and I > think there have already been conversations surrounding that. > > > > -Travis > > On Mar 13, 2026 at 1:33 PM -0700, Dmitri Bourlatchkov <[email protected]>, > wrote: > > > > > Hi All, > > > > > > Two PR have been proposed that remove unused values from > > > PolarisAuthorizableOperation: [3991], [3994]. > > > > > > EJ, made a point that these changes affect the Authorizer SPI and > general > > > Authorization vocabulary in Polaris, and that there might be > > > compatibility concerns. > > > > > > While I agree that these points have merit in general, as far as > Polaris is > > > concerned I'd like to offer a different perspective. > > > > > > At this point, Polaris as a project is still in very early stages of > code > > > maturity. Refractorings are very common and the java SPI / API surface > is > > > subject to changes in pretty much every feature proposal. Moreover, we > do > > > not yet have a formal SPI definition. Consequently, the standing > Polaris > > > Evolution doc [1] informs users that java code changes are to be > expected > > > at any time. Only the REST API is covered by SemVer "major change" > > > principles [2]. > > > > > > Re: authZ compatibility: Operation names indeed make their way into OPA > > > requests (as an example). However, given that the removed op names are > > > never requested by Polaris for authorization, there is not reason for > any > > > specific implementation to rely on them. > > > > > > If some authorizer policies do refer to the removed op names somewhere, > > > those references by nature are "soft links" and will not break after > > > removing the corresponding enum values from Polaris core. > > > > > > Re: authZ vocabulary: The unused enum values have no real meaning right > > > now. Documentation does not cover them and there is no code that could > be > > > used to deduce the meaning. Enum names themselves are probably too > weak to > > > define any particular behaviours expected of authorizer > implementations. > > > > > > Moreover, the removed op names appear to be very specific to the > Polaris > > > "native" RBAC model, so "external" authorizer (e.g. OPA, Ranger) > probably > > > do not need any special handling those operations even if Polaris used > them > > > in Authorizer calls. > > > > > > Other opinions are welcome. > > > > > > Should new use cases arise for the removed entities, we would restore > them, > > > of course. > > > > > > [1] https://polaris.apache.org/in-dev/unreleased/evolution/ > > > > > > [2] https://semver.org/ > > > > > > [3991] https://github.com/apache/polaris/pull/3991 > > > > > > [3994] https://github.com/apache/polaris/pull/3994 > > > > > > Cheers, > > > Dmitri. > > > > > >
