You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Debugging and obtaining visibility in general on the traffic handled by the wasm module is usually hard. One who tests a Kuadrant policy often has to enable Istio debugging options and scrap from the ingress gateway logs to spot even minor issues such as a typo in a policy. Frequently, Limitador logs are also used in combination.
Neither the path to get those logs enabled, nor the quality of the logs themselves always play much in favour of obtaining such level of visibility. To add the fact that inspecting the ingress gateway for logs (which is not a Kuadrant-owned component) may be counter-intuitive, despite usually the only (best) option.
So much tweaking with hard Istio configs and our own, to debug such a flexible resource as a Kuadrant policy does not seem coherent. IOW, debugging a policy should be we simple and easy as writing one.
Debugging and obtaining visibility in general on the traffic handled by the wasm module is usually hard. One who tests a Kuadrant policy often has to enable Istio debugging options and scrap from the ingress gateway logs to spot even minor issues such as a typo in a policy. Frequently, Limitador logs are also used in combination.
Neither the path to get those logs enabled, nor the quality of the logs themselves always play much in favour of obtaining such level of visibility. To add the fact that inspecting the ingress gateway for logs (which is not a Kuadrant-owned component) may be counter-intuitive, despite usually the only (best) option.
So much tweaking with hard Istio configs and our own, to debug such a flexible resource as a Kuadrant policy does not seem coherent. IOW, debugging a policy should be we simple and easy as writing one.
Related
The text was updated successfully, but these errors were encountered: