Offline validation for config passed to proxy wasm about spec HOT 5 OPEN

even if this function is added, Envoy/Istio has no way to report back to the users. Plus this seems essentially the same as the return value from the existing proxy_on_configure ABI. I suggest instead we just instantiate plugins at the control plane layer, and see the return value from proxy_on_configure

from spec.

from spec.

The original ABI had a function exactly like that, and Proxy-Wasm C++ SDK still has it (see: proxy_validate_configuration, RootContext::validateConfiguration), but I'm not aware of any plugins using it.

Note there are a few problems with such approach:

1. proxy_validate_configuration might be only slightly different from proxy_on_configure(configuration), which can result in code duplication and both functions could easily get out-of-sync over time,
2. some plugins require access to runtime variables (e.g. environment variables or host metadata), which control plane might not know about,
3. some plugins fetch parts of configuration from remote HTTP/gRPC endpoints at startup.

Basically, proxy_validate_configuration might catch some errors (e.g. parsing), but it cannot catch all of them, and it could introduce false negatives, so it's not a replacement for the proper solution (i.e. Envoy rejecting the configuration, and Istio propagating this information back to the operator).

from spec.

Another consideration here is that we access to those content types that
are being inspected and only buffer when inspection.

Could you elaborate? I don't understand how this is related to control plane performing config validation.

from spec.

proxy_validate_configuration might be only slightly different from proxy_on_configure(configuration), which can result in code duplication and both functions could easily get out-of-sync over time

Agree and I think the main difference between the two is the output but functionality wise they are quite similar.

some plugins require access to runtime variables (e.g. environment variables or host metadata), which control plane might not know about,some plugins fetch parts of configuration from remote HTTP/gRPC endpoints at startup.

Agree, this is mainly a best effort to allow users to validate the config offline.

So providing the method in the wasm extension isn't a perfect solution it just guarantees cohesion meaning that the same wasm that is running in prod is the one validating the config as opposed to provide another wasm (to be able to load it in different languages) or per language libraries (mostly limited to the wasm extension language)

from spec.