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. > > >
