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
ast: Adding rule_head_general_refs capabilities feature flag #6346
Conversation
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>
✅ Deploy Preview for openpolicyagent ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
docs/content/deployments.md
Outdated
{ | ||
"features": [ | ||
"rule_head_ref_string_prefixes", | ||
"rule_head_general_refs" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep wondering if...
- the implication should somehow be reflected -- you cannot have rule_head_general_refs without rule_head_ref_string_prefixes, since the latter is implied.
- naming: rule_head_ref could be the general case, _string_prefixes the limited one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I don't think I follow. You currently can't have
rule_head_general_refs
without alsorule_head_ref_string_prefixes
. We could add a more specific error message for when the former is present but not the latter. - would that not change the semantics of
rule_head_ref_string_prefixes
?
There was a problem hiding this comment.
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:
- 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.
- 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"
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😈 😄.
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
…le version calculation Signed-off-by: Johan Fylling <johan.dev@fylling.se>
capabilities/v0.59.0.json
Outdated
There was a problem hiding this comment.
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", | ||
}, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
To signal support for general refs in rule heads.
Fixes: #6334