Does Opal replaces OPA Bundles?

[yuval-k]

OPA supports Bundles as a way to dynamically load config.
How does Opal complements OPA bundles? is it more holistic approach to an OPA control plane?

[asafc]

Hi @yuval-k :) what a great question!

This is the way it works now with policy updates:

1. OPAL server monitors a repository, and specifically all the .rego /data.json files (which are opa bundle compliant)
2. When OPAL server detects commits that affect such files, it sends an update notification via pub/sub to the OPAL client that is subscribed to the relevant directories in the source code repository (the update also includes the commit hash of the top commit).

• By default opal clients subscribe to the entire directory, but this can be changed via configuration variable.
• The thinking is that you can have a separate "bundle" directories per tenant, installation, etc.

3. OPAL client checks the commit hash against the latest one it knows, and then issue a REST API request to https://opalserver/policy endpoint, which returns an OPAL policy bundle, which is almost 1:1 the same as the OPA bundle format.
   • You can check out what is returned from /policy here: Bundle API docs
   • please note that if the base_hash param is provided, a "delta bundle" will be returned (only changes between the base hash commit and the new latest commit)
4. OPAL client then applies the changes from the returned bundle into OPA via OPA's REST API (i.e: policy api and data api).

The thinking behind this design:

• There is no way currently in the OPA API to ask OPA to apply a bundle.
• OPA can only be configured to poll for new bundles from a bundle server every interval.

Possible changes i can think of:

• Make the bundle format returned by the opal server /policy endpoint the same as OPA's bundle format - meaning a tar will be returned.
  • That will necessitate creating another API for "delta bundles" if we still want to keep this feature for performance.
• Another option is to push the bundle as part of the update notification itself (on top of pub/sub) - i don't like it as much, i think pushing a lot of data via websocket is prone to potential problems.

We are open to making changes. WDYT? :)

[yuval-k]

Thank you for the detailed answer!
This sounds like you are aiming for gitops approach to OPA policies? i.e like flux is to k8s, opal is to opa? is that a good way to look at it (I'm trying to build a mental model)?

[yuval-k]

How would you go about observing that the opal client is connected to the server?
Do you plan to expose a metrics?
Or rely on the metrics that OPA reports ?

[orweis]

Re: Gitops

Yes the policy-update channel of OPAL (to distinguish from the data-update channel) is defiently Gitops oriented- and can be aligned with your code's main CI/CD (but can also be part of an independent CI/CD if needed).

Re: "observing that the opal client is connected to the server"

The client (and the server) both provide a "\healthcheck" route by default
In addition the client (and the server) provide flexible configuration for structured logging (via loguru) these can be adapted into metrics with something like Prometheus.
That said, it might be worth considering adding a more explicit metrics route / (other medium)