API transactional operations

[juanpablojofre-dell]

API transactional operations

Are there any intentions on having transactional operations for the API, for the Policy and Data requests that alter the contents of the OPA server?

All our policies and data for a given use case are 'saved' in git repository. Sometimes (very often) either policies or data get updated, altered, deleted, etc. in 1 commit (through a PR process); finally, we could deploy the entire data set to each OPA service, or we could push only the changes (instead of the full package).

In the case of pushing the changes to the OPA service, is there a mechanism to guarantee that either all changes get deployed or none if something fails?

It would be nice to have something like:

• POST /v1/change
{ "op": "start"} | {"op": "complete"} | {"op": "discard"}

So, your changes can safely be deployed and your sever is always in good known state.

[charlieegan3]

Hi @juanpablojofre-dell, there's a lock used when updating the internal store so it's not possible that two concurrent requests would race on the same update. However, we don't have something like a database transaction to rollback all earlier operations when something fails.

The closest to the behaviour you describe is the Delta bundle option where if a patch fails the data bundle is not activated and OPA waits for new data before trying again. Exposing the data in the git repo as a delta bundle API might be an option for you. However, this is not available for policy.

Generally the best way to update the policy state is via the bundle api - have you considered this?