In which order are adapter processed

Hello,

I try to understand how the Policies and Telemetry are working. I have been playing around with white listing, black listing and denier. In which order are rules, handler and instances executes, if more that one matches and can they block each other? In example I created first a whitelisting functionality and then a denier. The result (at least for me) is that denier will block everything even before the whitelisting is “executed”. Can I change the order to get a different result?

Thank you very much in advance,

Olaf

Hi!

The order is the least surprising: it’s a logical OR, e.g. if any rule blocks, then the result is rejection. Note there is some extra information attached to the rejection (max-use-count and max-duration) which is trivially aggregated in case of acceptance (by taking a minimum).

The model is limited and we’ve talked in the past about extending it to allow explicit white-listing behavior (e.g. if one adapter accepts, ignore others). The resolution was a new config, a policy document that could make these invocations more explicit and allow ordering them or taking ANDs of results. We actually sort of made transition in the existing Rule config, with the only missing piece being “a logical expr” over handler results. However, given the new architectural direction of Mixer this work froze in this state. The workaround appears to be to push down the complexity into the adapter itself and not rely on Mixer to order/compose denier results.

Best,
–kuat

Hello Kuat,

thank you for the answer. Is my assumption correct the adapters for mertics, logging and so on are still executed?

Kind regards,

Olaf

Hi,

Yes, telemetry adapters also execute in parallel. There is a little bit more complexity with regards to batching, but logically, Mixer dispatches adapter calls in parallel and waits for them to complete.

There is a special case of attribute-producing adapters that always run first before either telemetry or policy adapters. It is a special case, and only used to populate Kubernetes metadata from pod IDs.

Hello,

could you point me to the documentation, where I can find this information, because I have only found information how to develop adapters, but not much information how the mixer is working in respect to policies and telemetry adapter.

Again thank you very much for the help.

Hi!

I don’t think we have an architecture document that is up to date. We’re happy to answer any other questions about the design of policy&telemetry, and you’re also welcome to look around the code base, especially in the runtime part of it https://github.com/istio/istio/blob/52e9659759c01fa91701dfc1d4da72abd9aa1f1a/mixer/pkg/runtime/dispatcher/dispatcher.go
I find it fairly readable, speaking as someone who did not actually write this code.

Keep in mind that given the new architectural direction to move Mixer functionality into the proxy, there will be major changes to how the runtime behaves.
–kuat

Thank you very much. You help me a lot.