Context propagation in OPA

[purcarasugabi]

Hi, I have a question regarding the context propagation support in OPA. My use case looks like this:

We are using the discovery feature with the bundle API and we have some OPA pods that are using a control plane service to download and activate the bundle.

My question is, how can i trace all this actions?

My first idea was to start a trace in the service that builds the bundle, propagate the context to the .manifest file and then, using the Status API, to push the context from OPA pods to the control plane service. However, this workaround is not working because we are using the discovery feature and I saw in the documentation that the manual status reporting is not working with the discovery feature.

Is there any out of the box support for context propagation in OPA via the bundle API?

Thank you!

[srenatus]

Is there any out of the box support for context propagation in OPA via the bundle API?

No. The bundle API will retrieve something from the bundle server -- it would be quite uncommon to use the response headers from that for subsequent status POSTs, I think.

But every bundle has a hash associated (called "revision", I think) and that'll be used in decision logs -- so it should give you some idea of where the bundle goes. You can surely figure that rev out on your bundle service, too.

Is this helpful at all? 🙃 hope a little.

[purcarasugabi]

Thank you for such a fast reply!
Indeed, a behavior like that would be quite uncommon.

Sorry, i wasn't specific enough. By propagating the context to the manifest file I was thinking about something like setting the bundle revision to somethig like {traceId}_{spanId}, both traceId and spanId being generated by the bundle service.

The missing part here is that we want to be "notified" somehow by the OPA that the new bundle was activated.

We managed to obtain this kind of behavior using the Status API, when the OPA sent the status to the bundle service with that revision id.

Unfortunately this approach is not working with the discovery feature. Is there a reason why the status API is not working with the discovery feature?

[srenatus]

Unfortunately this approach is not working with the discovery feature. Is there a reason why the status API is not working with the discovery feature?

I'm not sure I understand. I think the bundle revision is in the DL entries, so you should be able to notice that the bundle was activated and evaluated by observing the DL stream. There's no DL "event" for a successful bundle activation, you only get that through the Status API.

[purcarasugabi]

Thank you for the clarifications!
So we will stick to the status API for bundle activation event.

Let me rephrase the previous question.
In the discovery feature documentation it is stated that "If discovery is enabled, other features like bundle downloading and status reporting cannot be configured manually"
My question is why the status reporting cannot be configured manually when the discovery feature is enabled? Is this a design limitation or is something that could be done, but is not implemented yet?
I am asking because this feature would be really helpful in my project and if it is something that could be done, maybe i could contribute to this feature.

[srenatus]

My question is why the status reporting cannot be configured manually when the discovery feature is enabled?

You can think of discovery mode as having OPA purely remote controlled: every aspect is controlled by the control plane which does that via discovery bundles. So it's a limitation by design.

[purcarasugabi]

Oh, i see. Thank you for clarification!