* when manually triggering, make sure the latest status event is registered. Only one status event should exist.
* read bundle status for snapshot as well
* revert back to buffering 1 status event
Signed-off-by: sspaink <sspaink@styra.com>
Following #7528, we also need to route any requests using the old
versioned paths to the correct location.
Signed-off-by: Charlie Egan <charlie@styra.com>
If a status API is slow to respond it can cause OPA to be blocked writing to an unbuffered channel. This fixes it by using a buffered channel that never blocks but drops the oldest status update if full.
Signed-off-by: Sebastian Spaink <3441183+sspaink@users.noreply.github.com>
This commit stores parsed GraphQL schemas to the cache, which improves
the performance of GraphQL operations that parse the schema more than once.
Queries are not cached.
Resolves: #5377
Signed-off-by: Rob Myers <1243316+robmyersrobmyers@users.noreply.github.com>
fix: don't panic on format due to unexpected comments
comments next to object elements is valid rego, instead of panicking
catch the error and write the rule as-is.
Signed-off-by: sspaink <sspaink@styra.com>
Making Partial Eval (PE) respect default functions.
Before this fix, Rego functions with declared default values weren't respected by PE, and the default declaration was omitted from generated support modules.
Fixes: #7220
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
to allow for using Rego v1 bundles in `opa build`/`check`/`eval`/`test`.
Before this change, a bundle with `1` as `rego_version`/`file_rego_versions` would be rejected when evaluated with the `--v0-compatible` flag with the error:
```
rego_parse_error: illegal capabilities: rego_v1 feature required for parsing v1 Rego
```
This is fixed by adding the `rego_v1` feature to the `v0` default capabilities applied when using the `--v0-compatible` flag. Note: this allows OPA to accept Rego `v1` modules inside bundles, but modules without a specified Rego version, such as freestanding non-bundle modules or modules inside bundles with no specified Rego version, are parsed as `v0`.
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
Similar to how some other built-in functions have been optimized previously,
the `lower` and `upper` functions now return the operand as-is when the string
wasn't modified by the operation. The impact of this check is negligible when
the string is modified, and as the benchmarks demonstrate, quite an improvement
for the cases where it isn't. For those, we no longer need to allocate at all.
Signed-off-by: Anders Eknert <anders@styra.com>
The previous update of this bundle was a corrupted tarball that OPA was unable to read.
```bash
$ opa eval -b helm-kubernetes-quickstart 'data'
{
"errors": [
{
"message": "loading error: bundle helm-kubernetes-quickstart: bundle load failed on manifest decode: invalid character '\\x00' looking for beginning of value"
}
]
}
```
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
For me installing docker (desktop on Mac) wasn't enough to use kind. I had to install kind. This is compatible with the kind installation instruction which specifies to install kind after installing docker.
Additionally just installing docker isn't enough. It needs to be running. The docker info is a bit confusion in this regard, because if it's installed but not running, it will show output compatible with the example in the tutorial.
Since this tutorial isn't (much) about docker, and the kind installation instructions I'd suggest to strike the rest of the text and just refer to the kind usage/installation instruction, which was already there.
Signed-off-by: Joost Holslag <joostholslag@users.noreply.github.com>
Apparently setting a license key is not (longer?) needed. The tutorial doesn't mention it in the rest of the text as the deleted line promises. I couldn't find a hidden statement about a license key in the config files. Not does the page on installing opa using docker mention a license key. https://www.openpolicyagent.org/docs/latest/deployments/
Signed-off-by: Joost Holslag <joostholslag@users.noreply.github.com>
This new event-based buffer provides a performance improvement over
the existing buffer by reducing locks and allowing concurrent writes and uploads.
The buffer size is managed by number of individual events opposed to total bytes.
Signed-off-by: sspaink <sspaink@styra.com>
While the double newline added by the formatter after each rule makes sense
for most rules, short one-liner rules should be groupable. This PR changes
the behavior of the formatter, so that if the user does:
```rego
x := 1
y := 2
```
That is no longer formatted into:
```rego
x := 1
y := 2
```
If the user **wants** double newlines between one-liner rules, the formatter
respects those when present.
Note that the `default` rules are excepted even when a one-liner, as presenting
these separately helps understanding the policy.
Fixes#6760
Do note that the issued mentioned doing this only for incremental rules, i.e.
to group only rules of the same name. I changed my mind on that though, as grouping
"constants" should be possible too.
Signed-off-by: Anders Eknert <anders@styra.com>
slack.openpolicyagent.org redirected to communityinviter. This service
is now migrated to inviter.co and should be used instead. I have not yet
updated the redirect, but when this has been done, we can revert the
change to refer to slack.openpolicyagent.org.
Signed-off-by: Charlie Egan <charlie@styra.com>
When planning rules like these:
```
package authz
p.allow[action][resource] if { action := "list"; resource := "fruit" }
p.unrelated.eat.veggies if true
resp := p[input.rule][input.action][input.resource]
```
we ended up with a broken CallDynamic statement. Since the first ref
rule is planned as `g0.data.authz.p.allow` and builds an object return
value, and the second rule is planned as
`g0.data.authz.p.unrelated.eat.veggies` with a boolean return value, we cannot
dynamically dispatch their calls.
With this change, the previously existing "unbalanced ruletrie" check now
also hits before reaching the end of the ref. It'll catch this situation
and avoid optimizing the dispatch. We'll end up with a longer, less
efficient, but correct plan.
Signed-off-by: Stephan Renatus <stephan@styra.com>
Johan Fylling