Simplified Deployment For Envoy/WASM Traffic Sources

[the-wondersmith]

Cutting out a ton of backstory / context, a recent deployment of API Clarity to a cluster that was already running Istio resulting in discovering a much simpler method of applying the WASM filter. I think it would be extremely beneficial to replace the extant method with it.

I've written up a gist that explains it here, but the short version is that it eliminates the need for the post-install patching job, the ConfigMap(s) containing the WASM filter binary, and the associated annotations/configuration for the Istio sidecar(s).

If there's interest, I would be very interested in working with a member of the API Clarity team to get it worked into the API Clarity / WASM filter repos.

[the-wondersmith]

@klyr @jubarbot-cisco or any other maintainer team member - would love to get your input on this

[akpsgit]

Hi @the-wondersmith, thank a lot for opening the issue. So the suggestion is set the URL of the WASM binary in the filter and using the label selectors to attach it to Envoy proxies? Will the URL point to the WASM binary release?
A contribution will be really appreciated. Thanks!

[the-wondersmith]

@akpsgit That's more or less correct, yes. If y'all are open to a PR I'll try to put one together this week.

Any thoughts on which repo the PR should be made to (apiclarity or wasm-filters) ? I've been on vacation for the last week, so I need to take another look at things, but I think handling things this way would actually alleviate the need to have wasm-filters as a sub-repo of api-clarity. Thoughts?