feat(conf_loader): load all WASM filters from conf path

[locao]

Summary

Load WASM filters from configured path.

Checklist

• The Pull Request has tests
• There's an entry in the CHANGELOG
• There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Full changelog

• load wasm filters from configured path.
• do not expect individual files.
• added new directive to template.

Issue reference

KAG-500

[hbagdi]

I'm not sure but do you think it is reasonable to add an explicit "KONG_WASM" or similar configuration option to globally enable/disable wasm support in Kong, at least until it is stable enough that we deem it to be production-grade?

[thibaultcha]

The tech preview branch had the wasm = on/off flag that superseded the wasm_modules property, but this PR removed it to fully depend on whether or not .wasm files are present in the directory we point to. I guess the question is do we want to enable wasm support only depending on whether or not .wasm bytecode is detected, or do we want a boolean flag to enable on top of that first condition. Personally I have no opinion, only wanted to clarify what we have and what we can do.

[hbagdi]

I guess the question is do we want to enable wasm support only depending on whether or not .wasm bytecode is detected, or do we want a boolean flag to enable on top of that first condition.

I lean towards having a boolean flag that serves as the main flag to enable/disable WASM support. The rationale is that sometimes the operator would like to disable WASM (for any reason) without removing the .wasm bytecode files, which may be baked into the container image, and changing the container image would require more hassle than is strictly necessary.

[locao]

disable WASM (for any reason) without removing the .wasm bytecode files, which may be baked into the container image

Having the wasm files baked in the container image was something I wasn't considering. So, yes, it makes sense to have a boolean flag.

[flrgh]

Since we're leaning towards using the boolean wasm = on|off setting to toggle wasm, would it make sense to remove wasm_filters_path as a setting and use a standardized location (i.e. {{KONG_PREFIX}}/wasm_filters) instead?

We can always add wasm_filters_path later on if there is a compelling case to use a non-default location.

@locao what do you think?

[locao]

I don't have a strong opinion on this. I like a lot of knobs to adjust even if they were never touched, but that's not how a good product is built 😅

For the sake of keeping things simpler, I'd say let's try without wasm_filters_path and see if we miss using it during development phase.

[flrgh]

I can imagine it being kind of annoying for our integration tests if the path is not configurable, but in my opinion this gives us the incentive to make sure symlinks are supported. Ideally something like this should be supported out-of-the box:

ln -s \
  /path/to/git/kong/spec/fixtures/wasm/a/b/c/d/my_filter.wasm \
  /path/to/my_kong_prefix/wasm_filters/my_filter.wasm