opa
opa copied to clipboard
Patch an already activated bundle
What is the underlying problem you're trying to solve?
As an OPA plugin developer, I would be able to load OpPatches on the go. That mean, I want to push Patches into my current activated bundle. There is an internal function available that act like this : https://github.com/open-policy-agent/opa/blob/b18b0a26bb22e1b661360d03eff62f2d17c43544/bundle/store.go#L918
Describe the ideal solution
The ideal solution would be to make this function Public to everyone.
Describe a "Good Enough" solution
Document a way to load patches into an activate bundle using the actual OPA "std" lib.
Hey there, thanks for the issue and the PR proposal.
Hope you don't mind me asking -- what's the use case here? Perhaps there are other ways to address this than messing with an activated bundle? I think it would perhaps be troublesome, since you cannot tell what's running if something has potentially done something; so the bundle revisions etc und the decision logs aren't as meaningful anymore... 💭
Hey @srenatus !
My use case is : I'm hydrating my OPA store thanks to an external data-source. In this data-source there is versioned snapshots and deltas bundles. Given I will load the latest bundle when OPA start by activated it in my store, I will be unable to push changes from a new delta bundle using SDK.
It don't know if there is a way to handle this behavior, but if it is the case it's at least not documented.
@ashutosh-narkar can you have a look, please? ☝️
@Joffref have you considered using the Activate method. That would be a better way to go about this instead of making applyPatches public.
Yes for sure, but there is a problem when you activate only patches, indeed there is a roots path overlapping. I think the best way to do this is to load the bundle in store and activate it with patches but it's a massive overhead to do a simple action as patching the store.
From what I understood earlier, I thought you have a snapshot bundle activated in the store and now you want to activate a delta bundle. Is that the case? If yes, then invoking the Activate method would be the right path as it would ensure the constraints around bundles are honored. If you simply want to patch the store you can use the methods provided by the storage package.
The problem is : when you have a snapshot bundle activated in your store and you want to apply a Delta bundle using Activate, Activate throw an error about roots and bundle path overlapping unless you merge the two bundle, it's too much overhead and I think it would be valuable for OPA to introduce this "unsafe" behavior.
Activate throw an error about roots and bundle path overlapping unless you merge the two bundle
The purpose of the Activate call is to activate a bundle (delta or snapshot) while adhering to some rules OPA defines for them specifically around manifests. See this for more info. If you want to avoid these checks and simply patch data from a delta bundle to a snapshot in store, you could use the methods exposed by the storage package. This is what the applyPatches uses too. Ideally you want to structure your delta bundles in a format expected by OPA.
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.
Closing this as OPA's storage package provides the necessary functions to patch data.