Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat(wasm): add wasm plugin interface #13843

Merged
merged 4 commits into from
Nov 15, 2024
Merged

feat(wasm): add wasm plugin interface #13843

merged 4 commits into from
Nov 15, 2024
+774 −139

Conversation

flrgh
Copy link
Contributor

@flrgh flrgh commented Nov 7, 2024 •
edited
Loading

Summary

This adds a new interface to wasm filters, allowing users to configure them in the same manner as a plugin entity.

From the admin API/database/plugin entity side of things, inspiration was taken from the implementation of plugin servers, so there are parallels with regards to how filters and their schemas are discovered. Some refactoring was done so that the filter Lua schema could be reused between both the filter_chain entity and this new plugin schema interface.

This feature works in concert with the existing filter chain model. On the runloop side, we iterate over plugin entities to discover the wasm filters and create proxy-wasm filter chains on-the-fly. When an existing filter_chain entity exists for a service/route, we append filters to it.

Checklist

Issue reference

KAG-5616

@github-actions github-actions bot added core/proxy core/db core/configuration schema-change-noteworthy cherry-pick kong-ee schedule this PR for cherry-picking to kong/kong-ee core/wasm Everything relevant to [proxy-]wasm labels Nov 7, 2024
@flrgh flrgh marked this pull request as ready for review November 7, 2024 17:48
@flrgh flrgh requested review from brentos and locao November 7, 2024 17:48
flrgh
flrgh commented Nov 7, 2024
View reviewed changes
kong/db/schema/init.lua Outdated Show resolved Hide resolved
@flrgh flrgh force-pushed the feat/wasm-plugins branch 4 times, most recently from 9e4e054 to a8fee3c Compare November 11, 2024 17:34
locao
locao reviewed Nov 12, 2024
View reviewed changes
Copy link
Contributor

@locao locao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about the dbless tests?

spec/02-integration/20-wasm/12-filters-as-plugins_spec.lua Show resolved Hide resolved
kong/conf_loader/init.lua Outdated Show resolved Hide resolved
kong/db/schema/init.lua Show resolved Hide resolved
kong/db/schema/others/wasm_filter.lua Outdated Show resolved Hide resolved
locao
locao approved these changes Nov 13, 2024
View reviewed changes
Copy link
Contributor

@locao locao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Way to go! 🚀

brentos
brentos reviewed Nov 13, 2024
View reviewed changes
kong/db/schema/init.lua Outdated Show resolved Hide resolved
brentos
brentos reviewed Nov 13, 2024
View reviewed changes
kong/db/schema/init.lua Outdated Show resolved Hide resolved
@flrgh flrgh merged commit 4059a31 into master Nov 15, 2024
28 checks passed
@flrgh flrgh deleted the feat/wasm-plugins branch November 15, 2024 20:39
@team-gateway-bot
Copy link
Collaborator

Cherry-pick failed for master, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally.

git remote add upstream https://github.com/kong/kong-ee
git fetch upstream master
git worktree add -d .worktree/cherry-pick-13843-to-master-to-upstream upstream/master
cd .worktree/cherry-pick-13843-to-master-to-upstream
git checkout -b cherry-pick-13843-to-master-to-upstream
ancref=$(git merge-base f88da7df62cb3cbc7dbd4150756571d1b7928198 7c13e4461651d49212cc00754cbf9fb3fd0b11a2)
git cherry-pick -x $ancref..7c13e4461651d49212cc00754cbf9fb3fd0b11a2

@github-actions github-actions bot added the incomplete-cherry-pick A cherry-pick was incomplete and needs manual intervention label Nov 15, 2024
@flrgh flrgh removed the incomplete-cherry-pick A cherry-pick was incomplete and needs manual intervention label Nov 15, 2024
flrgh added a commit that referenced this pull request Nov 26, 2024
@flrgh
fix(plugins): load wasm filter plugins before external plugins
caa921b 
In 4059a31 (#13843) we added a
plugin-like interface for Wasm filters.

We now have 3 sources for plugins: Lua, External, and Wasm Filters. When a plugin is enabled or configured, the plugin system follows a
resolution order for looking up the plugin handler and schema:

1. Lua => `require kong.plugins.<name>.{handler,schema}`
2. External => `kong.runloop.plugin_servers.load_{handler,schema}(<name>)`
3. Wasm Filters => `kong.runloop.wasm.plugins.load_{handler,schema}(<name>)`

When a user configures Kong with a "bad" entry in `pluginserver_names`
(read: a plugin server that is not actually installed), step #2 of the
plugin resolution process throws an exception, because the external
plugin subsystem attempts to query a plugin server that does not exist.
Importantly, *this exception is not encountered when the user has only
configured/enabled Lua plugins,* because we never reach beyond step #1
of the plugin resolution process.

A side effect of adding the Wasm filter plugin interface is that
discovered Wasm filters are added to the global plugins table
(`kong.configuration.loaded_plugins`) when Wasm is enabled. This means
that, if Wasm is enabled, and any Wasm filters are installed, we
_always_ step through step #2 of the plugin resolution process,
triggering an exception if the user has any badly-configured plugin
server.

A future change will likely render this scenario unreachable by
performing deeper validation of `pluginserver_names` at startup. For
now, a simple fix is just to change the resolution order such that Wasm
filters are loaded _before_ we query the external plugin subsystem:

1. Lua
2. Wasm Filters
3. External
@flrgh flrgh mentioned this pull request Nov 26, 2024
Merged
3 tasks
flrgh added a commit that referenced this pull request Nov 26, 2024
@flrgh
fix(plugins): load wasm filter plugins before external plugins
35bc851 
In 4059a31 (#13843) we added a
plugin-like interface for Wasm filters.

We now have 3 sources for plugins: Lua, External, and Wasm Filters. When a plugin is enabled or configured, the plugin system follows a
resolution order for looking up the plugin handler and schema:

1. Lua => `require kong.plugins.<name>.{handler,schema}`
2. External => `kong.runloop.plugin_servers.load_{handler,schema}(<name>)`
3. Wasm Filters => `kong.runloop.wasm.plugins.load_{handler,schema}(<name>)`

When a user configures Kong with a "bad" entry in `pluginserver_names`
(read: a plugin server that is not actually installed), step #2 of the
plugin resolution process throws an exception, because the external
plugin subsystem attempts to query a plugin server that does not exist.
Importantly, *this exception is not encountered when the user has only
configured/enabled Lua plugins,* because we never reach beyond step #1
of the plugin resolution process.

A side effect of adding the Wasm filter plugin interface is that
discovered Wasm filters are added to the global plugins table
(`kong.configuration.loaded_plugins`) when Wasm is enabled. This means
that, if Wasm is enabled, and any Wasm filters are installed, we
_always_ step through step #2 of the plugin resolution process,
triggering an exception if the user has any badly-configured plugin
server.

A future change will likely render this scenario unreachable by
performing deeper validation of `pluginserver_names` at startup. For
now, a simple fix is just to change the resolution order such that Wasm
filters are loaded _before_ we query the external plugin subsystem:

1. Lua
2. Wasm Filters
3. External
gszr pushed a commit that referenced this pull request Nov 27, 2024
@flrgh @gszr
fix(plugins): load wasm filter plugins before external plugins
b1cf758 
In 4059a31 (#13843) we added a
plugin-like interface for Wasm filters.

We now have 3 sources for plugins: Lua, External, and Wasm Filters. When a plugin is enabled or configured, the plugin system follows a
resolution order for looking up the plugin handler and schema:

1. Lua => `require kong.plugins.<name>.{handler,schema}`
2. External => `kong.runloop.plugin_servers.load_{handler,schema}(<name>)`
3. Wasm Filters => `kong.runloop.wasm.plugins.load_{handler,schema}(<name>)`

When a user configures Kong with a "bad" entry in `pluginserver_names`
(read: a plugin server that is not actually installed), step #2 of the
plugin resolution process throws an exception, because the external
plugin subsystem attempts to query a plugin server that does not exist.
Importantly, *this exception is not encountered when the user has only
configured/enabled Lua plugins,* because we never reach beyond step #1
of the plugin resolution process.

A side effect of adding the Wasm filter plugin interface is that
discovered Wasm filters are added to the global plugins table
(`kong.configuration.loaded_plugins`) when Wasm is enabled. This means
that, if Wasm is enabled, and any Wasm filters are installed, we
_always_ step through step #2 of the plugin resolution process,
triggering an exception if the user has any badly-configured plugin
server.

A future change will likely render this scenario unreachable by
performing deeper validation of `pluginserver_names` at startup. For
now, a simple fix is just to change the resolution order such that Wasm
filters are loaded _before_ we query the external plugin subsystem:

1. Lua
2. Wasm Filters
3. External
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@locao locao locao approved these changes

@brentos brentos brentos approved these changes

Assignees

@flrgh flrgh

Labels
cherry-pick kong-ee schedule this PR for cherry-picking to kong/kong-ee core/configuration core/db core/proxy core/wasm Everything relevant to [proxy-]wasm schema-change-noteworthy size/XL
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@flrgh @team-gateway-bot @brentos @locao @hishamhm