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?
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.
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.
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.
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