Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ast: Adding rule_head_general_refs capabilities feature flag #6346

Conversation

johanfylling
Copy link
Contributor

To signal support for general refs in rule heads.

Fixes: #6334

To signal support for general refs in rule heads.

Fixes: open-policy-agent#6334
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
@netlify
Copy link

netlify bot commented Oct 26, 2023

Deploy Preview for openpolicyagent ready!

Name Link
🔨 Latest commit a47427a
🔍 Latest deploy log https://app.netlify.com/sites/openpolicyagent/deploys/6554978dd8545800087ad051
😎 Deploy Preview https://deploy-preview-6346--openpolicyagent.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

srenatus
srenatus previously approved these changes Oct 26, 2023
{
"features": [
"rule_head_ref_string_prefixes",
"rule_head_general_refs"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep wondering if...

  1. the implication should somehow be reflected -- you cannot have rule_head_general_refs without rule_head_ref_string_prefixes, since the latter is implied.
  2. naming: rule_head_ref could be the general case, _string_prefixes the limited one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I don't think I follow. You currently can't have rule_head_general_refs without also rule_head_ref_string_prefixes. We could add a more specific error message for when the former is present but not the latter.
  2. would that not change the semantics of rule_head_ref_string_prefixes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I was a bit too brief:

  1. I was wondering if it made sense to declare that both features as supported when one subsumes the other one. It's a bit like saying "All animals are allowed. And cows are allowed." 🙃 However, it probably simplifies things to keep them both, so it's OK, I think.
  2. I was thinking that "general refs" are just refs. "string prefixes" are the special case. So my proposal was to rename the new feature to "rule_head_refs"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the reason for why I didn't let one feature imply the other is out of concern that someone already has a procedure for stripping out rule_head_ref_string_prefixes from a capabilities-file generated by OPA, and if we introduce a new feature flag that will enable refs anyways, then their setup will start behaving against their configuration.
Of course, I think the risk of this is close to non-existent; but I'm hesitant to break an already established contract for rule_head_ref_string_prefixes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. What do you think about calling the new feature simply "rule_head_refs"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@srenatus @anderseknert wdyt about rule_head_general_refs implying rule_head_ref_string_prefixes?

I'd be in favor of that. Technically, I think we could even consider deprecating rule_head_ref_string_prefixes, since it's been a byproduct of how this feature got introduced; not really a desirable feature switch to have, in my opinion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically, I think we could even consider deprecating rule_head_ref_string_prefixes

Could we just remove it, without first deprecating it? Then we'd effectively just replace rule_head_ref_string_prefixes with rule_head_refs now.

Again, I'm not very familiar with how this is actually used, and what impact breaking changes have; but if we're willing to break an egg, perhaps we can thoroughly stomp on it 😈 😄.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we just remove it, without first deprecating it? Then we'd effectively just replace rule_head_ref_string_prefixes with rule_head_refs now.

👍 I think that's OK. @ashutosh-narkar ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. Let's just make sure we add a change log entry, message this in slack etc. to let the community know about this after we merge this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given how the minimal compatible version is calculated, I opted to go with @srenatus's first suggestion, and let the rule_head_refs capability map to all ref head rule permutations, and let rule_head_ref_string_prefixes map to the special case of string-prefix refs.

Copy link
Member

@tsandall tsandall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that #6348 has merged we need to update this PR to include the feature in the required capabilities that the compiler generates.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will it mess anything up that we add this now before the actual release?

p.a.b[c].d if { c := "foo" }
`,
version: "0.59.0",
},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added support for the rule_head_refs capability feature to the minimum compatible version calculation @tsandall .

How do we envision this working when we start removing capabilities, such as the deprecated built-ins?

Then, the following policy

package x
p { all([true, false]) }

will still output 0.17.0 as minimum version, but it won't be compatible with 1.0.
Will we just add a MaximumCompatibleVersion(), that'll output whatever the last supported version is for the capability?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't thought about the deprecated case. I wonder if a better interface would be to return the compatible version range?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that makes sense 👍 .
I wonder if this change fits better as part of #6361, though, as it wouldn't make much difference here.

@johanfylling johanfylling merged commit 56f2350 into open-policy-agent:main Nov 15, 2023
24 checks passed
@johanfylling johanfylling deleted the general_refs/capabilities_feature branch November 15, 2023 10:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add capabilities feature for general refs
4 participants