Consider using envoy route check tool

[howardjohn]

https://www.envoyproxy.io/docs/envoy/latest/install/tools/route_table_check_tool

It would be pretty interesting to directly use the envoy check tool mentioned above. That should allow much richer/lower maintenance test cases as you can cover all of Istio api surface.

I would imagine this looks like translating the istio config to envoy config then running through the envoy tool

[cainelli]

We have considered translating Istio config into Envoy but was afraid it wasn't fit into a hackday project as we wanted to delivery something concrete to add to our pipeline before applying the virtualservices.

This indeed looks a promising approach moving forward tho. Highly appreciate the input.

[howardjohn]

I think the biggest problem is also the fact that the envoy tool is based on routes, so you need a way to translate the request from the test to which route will be used. Normally that is handled by listeners/filter chain matching - hopefully we would not re-implement that logic. The actual part of running the istio -> envoy offline isn't super clean but we are working on improving it. https://github.com/istio/istio/blob/bdac0787e932c747154e996cfb2aabef6c820b88/pilot/pkg/xds/bench_test.go#L58 is a good example of doing it (and other stuff, so its a bit messier)

[cainelli]

Thanks, this reference will be quite useful and already gives me a direction, I will get more familiar with the tool and codebase and try to come up with a proof of concept after my vacation. Do you think this would be valuable for upstream istioctl? like istioctl analyze today. I haven't look at the code/dependencies, etc. to see how much work would be, just something I thought.

[howardjohn]

My main concern there is that it needs to call out to an external binary (the envoy tool). Might be easiest to ship it as a docker image of something that contains the go binary doing the logic and the envoy binary we call out to. That go binary may or may not be istioctl itself. Probably short term it would be it's own thing then possibly in the future it can be merged in

[cainelli]

yeah right, it makes sense. Let's start with that.

[cainelli]

An update on this old issue. I've built a prototype and we have been running internally in parallel with existing tooling.

To make it work with our existing tests I forked Istio proxy to build and patch the envoy router tool to work around runtime configuration issues. I've opened an issue envoyproxy/envoy#35174 to find a way forward without patching the tool.