You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Dmitri Bourlatchkov <di...@apache.org> on 2026/03/13 20:31:14 UTC
[DISCUSS] Removing unused entries from PolarisAuthorizableOperation
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.
Re: [DISCUSS] Removing unused entries from PolarisAuthorizableOperation
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi All,
While the SPI discussion has started, it hasn't been formally tracked.
I am +1 on creating an issue to track this and populating it with
references to our various discussions.
Regards,
JB
On Fri, Mar 13, 2026 at 9:33 PM Dmitri Bourlatchkov <di...@apache.org>
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.
>
Re: [DISCUSS] Removing unused entries from PolarisAuthorizableOperation
Posted by Yufei Gu <fl...@gmail.com>.
+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 <di...@apache.org>
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 <di...@apache.org>,
> 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.
> > >
> >
>
Re: [DISCUSS] Removing unused entries from PolarisAuthorizableOperation
Posted by Dmitri Bourlatchkov <di...@apache.org>.
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 <di...@apache.org>, 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.
> >
>
Re: [DISCUSS] Removing unused entries from PolarisAuthorizableOperation
Posted by Travis Bowen <tr...@gmail.com>.
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 <di...@apache.org>, 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.
>
Re: [DISCUSS] Removing unused entries from PolarisAuthorizableOperation
Posted by Sung Yun <su...@apache.org>.
Hi Dmitri,
I agree the risk here is low, since Polaris does not issue authorization requests for these operations today.
I do think it helps to separate three different contracts in the discussion related to compatibility:
1. SPIs, such as PolarisAuthorizer
2. public enum sets / authorization vocabulary, such as PolarisAuthorizableOperation
3. external integration contracts, such as the OPA request schema
I think grounding the discussion in those contracts, and in how they relate to each other, will help us define the right compatibility expectations at the right boundaries.
As a starting point, for SPI evolution, I think some amount of change is expected, especially at this stage of the project, at least for the authorization SPI. The impact of an incompatible change is usually fairly visible at upgrade time, for example when an integration no longer compiles.
For external request contracts, I think the compatibility bar should be higher, since those changes can affect deployed integrations more indirectly.
So for this specific change, removing unused PolarisAuthorizableOperation values seems reasonable to me. More generally, though, I think the project could more explicitly define how we want to handle backward compatibility for each of these contracts.
+1 on reviving the broader SPI discussion. I see that EJ picked up that issue already, I'm looking forward the discussions!
Cheers,
Sung
On 2026/03/13 20:31:14 Dmitri Bourlatchkov 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.
>