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.

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

Finish Cassandra DAO #1

Closed
11 tasks done
thibaultcha opened this issue Jan 30, 2015 · 13 comments
Closed
11 tasks done

Finish Cassandra DAO #1

thibaultcha opened this issue Jan 30, 2015 · 13 comments
Assignees
Milestone

Comments

@thibaultcha
Copy link
Member

  • Don't rely on models anymore, use it in a more functional way, such as:
factory.apis:insert {
  name = "api 1",
  public_dns = "hello.com",
  target_url = "http://httpconsole.org"
}
  • Static queries, prepared on start
  • Cassandra constraints: unique checks, exists checks for unique and foreign entities since not natively supported by Cassandra.
  • INSERT, UPDATE, SELECT, DELETE + tests
  • Dynamic SELECT (allowed fields)
  • deserialize SELECT output (json encoded/type)
  • Metrics INCREMENT + DELETE
  • Check all UNIQUE and FOREIGN fields from schema are written into __exists, __unique (tests or in :prepare)
  • Paginated SELECT
  • Proper error types
  • immutable property for values that cannot be updated
@thibaultcha thibaultcha self-assigned this Jan 30, 2015
@thibaultcha thibaultcha added this to the v0.1 milestone Jan 30, 2015
@thibaultcha
Copy link
Member Author

@thefosk

  • Why would an application not be attached to an account? Is an application possibly only linked to an API? Why so? I understand a plugin can only be linked to an API but not an application.

Attaching an application to an account_id could allow us to use account_id as a clustering key for better performance.

  • Why would an account's secret_key have to be unique?

Right now we have to maintain an INDEX on it only for this unique field. I understand the use case for an key authentication with an auto-generated api key (and we can just generate unique values). But isn't each user free to chose any password they want in the case the provider is using BASIC auth?

  • Why do we have to maintain an index on API's target_url? This is a very, very high cardinality value that will not be queried. (I don't see a use case)
  • Also we should RTFM more about all these options on tables:
DESCRIBE table metrics;

CREATE TABLE apenode.metrics (
    api_id uuid,
    application_id uuid,
    origin_ip text,
    name text,
    period text,
    "timestamp" timestamp,
    value counter,
    PRIMARY KEY ((api_id, application_id, origin_ip, name, period, "timestamp"))
) WITH bloom_filter_fp_chance = 0.01
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';
  • Why not enforcing map<string, string> on plugin's value column and make sure we store strings in it. Another good solution is we can have 2 columns: map<string, number>, and map<string, string> which is perfectly fine since cassandra is a column family DB. This unset map will not be set, and appear as null on CQL

TODO

We should start replacing the controllers code with the new DAO, as the main features are now finished.

@thibaultcha
Copy link
Member Author

Note for me Monday:

  • Pagination is supported by the driver in my fork no need to wait for PR yet, we duplicated the driver in Kong's code.
  • Fix this test by adding an api entity to a generated plugin. Best is to cache the Faker's inserted entities and randomly select one from there. Faster than random DB select.
  • Expose the page_state option to the base_dao and write tests for it.

Then just need to finish updating the controllers code.

@thibaultcha
Copy link
Member Author

We need a way to distinguish server errors from client errors in the DAO.

Cassandra error != Non existing FOREIGN key or failing UNIQUE check

@subnetmarco
Copy link
Member

The easiest solution I can think of is a response like:

local res, err, client_err, server_err = dao:do_something()

By having both err and client_err, server_err, it's up to the caller to decide if he needs a better drill down or not on the error. This will duplicate data.

It's up to the caller to parse it, for example if the caller doesn't care about the separation, he will just invoke the method the usual way:

local res, err = dao:do_something()

but if he does care, then he will add the other two variables:

local res, err, client_err, server_err  = dao:do_something()

So it's only going to be verbose only when the separation is required, not always.

@subnetmarco
Copy link
Member

Or err could be a table like:

local err = {
    client = {},
    server = {}
}

Or error messages could include a flag to tell if they're client or server errors, like:

local err = { public_dns = { message = "Invalid public dns", client = true } }

@thibaultcha
Copy link
Member Author

I think it's better practise to standardise the errors with a code. So all the errors wou'll be getting from the DAO will be

{
  type = "client",
  error = some_table
}

But sometimes the error can also be a string, is that an issue?

@subnetmarco
Copy link
Member

@thibaultcha the only problem that I see with your solutions (and with my last one, with the client flag), is that if we have both client and server errors then the caller will need to sanitize the error table before logging it or showing it to the user.

@thibaultcha
Copy link
Member Author

local error_codes = {
    [0x0000]= "Server error",
    [0x000A]= "Protocol error",
    [0x0100]= "Bad credentials",
    [0x1000]= "Unavailable exception",
    [0x1001]= "Overloaded",
    [0x1002]= "Is_bootstrapping",
    [0x1003]= "Truncate_error",
    [0x1100]= "Write_timeout",
    [0x1200]= "Read_timeout",
    [0x2000]= "Syntax_error",
    [0x2100]= "Unauthorized",
    [0x2200]= "Invalid",
    [0x2300]= "Config_error",
    [0x2400]= "Already_exists",
    [0x2500]= "Unprepared"
}
  • Those are Cassandra error codes. It is possible to receive a Cassandra error but it's actually a client error (passing an invalid UUID for example will be an "Invalid" error). I need to parse the error before deciding if client or server.
  • The only case when we could have both a client and a server error is in the UNIQUE and EXISTS checks (Cassandra.......................). Basically there might be a lot of UNIQUE and EXISTS checks at once (2 or 3 for some entities) and if an error is encountered, it adds it to the final error object. I need to interrupt the checks and return as soon as such an error is encountered. This way, no more aggregated errors.

@subnetmarco
Copy link
Member

@thibaultcha so what is the conclusion?

@thibaultcha
Copy link
Member Author

@subnetmarco
Copy link
Member

Excuse me?

@thibaultcha
Copy link
Member Author

Okay okay, this is now all done! Just need to finish to update the code and we can switch to #4 and #8 😄

@thibaultcha
Copy link
Member Author

At this point the DAO is finished and the refactor TODOs are now moved to #12

hutchic pushed a commit that referenced this issue Jun 10, 2022
)

### Summary

```
patching file LuaJIT-2.1-20200102/src/lj_api.c
patching file LuaJIT-2.1-20200102/src/lj_arch.h
Hunk #1 succeeded at 241 (offset 4 lines).
patching file LuaJIT-2.1-20200102/src/lj_cconv.c
patching file LuaJIT-2.1-20200102/src/lj_obj.h
Hunk #1 succeeded at 831 (offset 1 line).
patching file LuaJIT-2.1-20200102/src/lj_state.c
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core.lua
Hunk #1 succeeded at 19 with fuzz 1 (offset -2 lines).
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/ngx/balancer.lua
patching file lua-resty-core-0.1.19/lib/ngx/balancer.lua
Hunk #1 succeeded at 45 (offset 7 lines).
Hunk #2 succeeded at 348 (offset 137 lines).
patching file lua-resty-core-0.1.19/lib/resty/core.lua
patching file lua-resty-core-0.1.19/lib/resty/core/request.lua
patching file lua-resty-core-0.1.19/lib/resty/core/utils.lua
patching file lua-resty-websocket-0.07/lib/resty/websocket/client.lua
patching file nginx-1.17.8/src/http/ngx_http_upstream.c
Hunk #2 succeeded at 1688 (offset -3 lines).
Hunk #3 succeeded at 1719 (offset -3 lines).
Hunk #4 succeeded at 1765 (offset -3 lines).
patching file nginx-1.17.8/src/http/ngx_http_special_response.c
patching file nginx-1.17.8/src/stream/ngx_stream_proxy_module.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.h
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_common.h
patching file ngx_lua-0.10.17/src/ngx_http_lua_module.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_common.h
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_stream_lua-0.0.8/src/ngx_stream_lua_util.c
Hunk #1 succeeded at 1965 with fuzz 2 (offset 10 lines).
patching file ngx_stream_lua-0.0.8/src/api/ngx_stream_lua_api.h
```

vs.

```
patching file LuaJIT-2.1-20200102/src/lj_api.c
patching file LuaJIT-2.1-20200102/src/lj_arch.h
patching file LuaJIT-2.1-20200102/src/lj_cconv.c
patching file LuaJIT-2.1-20200102/src/lj_obj.h
patching file LuaJIT-2.1-20200102/src/lj_state.c
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/resty/core.lua
patching file lua-resty-core-0.1.19/lib/resty/core/socket_tcp.lua
patching file lua-resty-core-0.1.19/lib/ngx/balancer.lua
patching file lua-resty-core-0.1.19/lib/ngx/balancer.lua
patching file lua-resty-core-0.1.19/lib/resty/core.lua
patching file lua-resty-core-0.1.19/lib/resty/core/request.lua
patching file lua-resty-core-0.1.19/lib/resty/core/utils.lua
patching file lua-resty-websocket-0.07/lib/resty/websocket/client.lua
patching file nginx-1.17.8/src/http/ngx_http_upstream.c
patching file nginx-1.17.8/src/http/ngx_http_special_response.c
patching file nginx-1.17.8/src/stream/ngx_stream_proxy_module.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.h
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_socket_tcp.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_common.h
patching file ngx_lua-0.10.17/src/ngx_http_lua_module.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_lua-0.10.17/src/ngx_http_lua_common.h
patching file ngx_lua-0.10.17/src/ngx_http_lua_balancer.c
patching file ngx_stream_lua-0.0.8/src/ngx_stream_lua_util.c
patching file ngx_stream_lua-0.0.8/src/api/ngx_stream_lua_api.h
```
bungle added a commit that referenced this issue Jun 21, 2023
### Summary

#### bug fixes
- **\*:** fix typos and add error check for new_of/dup_of ([#2](fffonion/lua-resty-openssl#2)) [aa6ad47](fffonion/lua-resty-openssl@aa6ad47)

#### features
- **tests:** add performance test ([#112](fffonion/lua-resty-openssl#112)) [100b4e4](fffonion/lua-resty-openssl@100b4e4)
- **x509.store:** add store:check_revocation and add flag to skip check CRL for store:add ([#1](fffonion/lua-resty-openssl#1)) [1a5a4c8](fffonion/lua-resty-openssl@1a5a4c8)

Signed-off-by: Aapo Talvensaari <[email protected]>
bungle added a commit that referenced this issue Jun 22, 2023
### Summary

#### bug fixes
- **\*:** fix typos and add error check for new_of/dup_of ([#2](fffonion/lua-resty-openssl#2)) [aa6ad47](fffonion/lua-resty-openssl@aa6ad47)

#### features
- **tests:** add performance test ([#112](fffonion/lua-resty-openssl#112)) [100b4e4](fffonion/lua-resty-openssl@100b4e4)
- **x509.store:** add store:check_revocation and add flag to skip check CRL for store:add ([#1](fffonion/lua-resty-openssl#1)) [1a5a4c8](fffonion/lua-resty-openssl@1a5a4c8)

Signed-off-by: Aapo Talvensaari <[email protected]>
bungle added a commit that referenced this issue Sep 20, 2023
### Summary

Without this I get:
```
Hunk #1 succeeded at 121 (offset 8 lines).
Hunk #2 succeeded at 143 (offset 8 lines).
```

When applying the `ldp_stp_fusion` patch.

Signed-off-by: Aapo Talvensaari <[email protected]>
hanshuebner pushed a commit that referenced this issue Sep 26, 2023
### Summary

Without this I get:
```
Hunk #1 succeeded at 121 (offset 8 lines).
Hunk #2 succeeded at 143 (offset 8 lines).
```

When applying the `ldp_stp_fusion` patch.

Signed-off-by: Aapo Talvensaari <[email protected]>
bungle added a commit that referenced this issue Oct 30, 2023
### Summary

Before:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
Hunk #1 succeeded at 1133 (offset 26 lines).
Hunk #2 succeeded at 1142 (offset 26 lines).
```

After:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
```

Signed-off-by: Aapo Talvensaari <[email protected]>
bungle added a commit that referenced this issue Oct 31, 2023
### Summary

Before:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
Hunk #1 succeeded at 1133 (offset 26 lines).
Hunk #2 succeeded at 1142 (offset 26 lines).
```

After:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
```

Signed-off-by: Aapo Talvensaari <[email protected]>
team-gateway-bot pushed a commit that referenced this issue Oct 31, 2023
### Summary

Before:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
Hunk #1 succeeded at 1133 (offset 26 lines).
Hunk #2 succeeded at 1142 (offset 26 lines).
```

After:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
```

Signed-off-by: Aapo Talvensaari <[email protected]>
(cherry picked from commit dda623d)
dndx pushed a commit that referenced this issue Nov 9, 2023
### Summary

Before:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
Hunk #1 succeeded at 1133 (offset 26 lines).
Hunk #2 succeeded at 1142 (offset 26 lines).
```

After:
```
patching file bundle/LuaJIT-2.1-20230410/src/lj_asm_arm64.h
```

Signed-off-by: Aapo Talvensaari <[email protected]>
(cherry picked from commit dda623d)
samugi pushed a commit that referenced this issue Nov 9, 2023
Without this I get:
```
Hunk #1 succeeded at 121 (offset 8 lines).
Hunk #2 succeeded at 143 (offset 8 lines).
```

When applying the `ldp_stp_fusion` patch.

Signed-off-by: Aapo Talvensaari <[email protected]>
samugi pushed a commit that referenced this issue Nov 14, 2023
Without this I get:
```
Hunk #1 succeeded at 121 (offset 8 lines).
Hunk #2 succeeded at 143 (offset 8 lines).
```

When applying the `ldp_stp_fusion` patch.

Signed-off-by: Aapo Talvensaari <[email protected]>
samugi pushed a commit that referenced this issue Nov 15, 2023
Without this I get:
```
Hunk #1 succeeded at 121 (offset 8 lines).
Hunk #2 succeeded at 143 (offset 8 lines).
```

When applying the `ldp_stp_fusion` patch.

Signed-off-by: Aapo Talvensaari <[email protected]>
aaronhmiller added a commit to aaronhmiller/kong that referenced this issue Mar 22, 2024
…olicy_securityScan_120-google.golang.org/grpc_1.39.0

Upgrade dependency
curiositycasualty pushed a commit that referenced this issue Oct 15, 2024
flrgh added a commit that referenced this issue Oct 16, 2024
This adds a check during `init` that will prevent Kong from starting if
any filter chain entities are found in the database using a filter that
is not installed. Example:

> Error: ./kong/cmd/start.lua:99: nginx: [error] init_by_lua error: /path/to/kong/init.lua:750: [wasm]: found one or more filter chain entities with filters that are not enabled/installed:
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #1 (response_transformer)
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #3 (response_transformer)

Previously, this condition would not be caught until the Wasm state is
built during `init_worker`. This change brings Wasm more in line with the
behavior of the plugins iterator.
flrgh added a commit that referenced this issue Oct 16, 2024
This adds a check during `init` that will prevent Kong from starting if
any filter chain entities are found in the database using a filter that
is not installed. Example:

> Error: ./kong/cmd/start.lua:99: nginx: [error] init_by_lua error: /path/to/kong/init.lua:750: [wasm]: found one or more filter chain entities with filters that are not enabled/installed:
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #1 (response_transformer)
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #3 (response_transformer)

Previously, this condition would not be caught until the Wasm state is
built during `init_worker`. This change brings Wasm more in line with the
behavior of the plugins iterator.
flrgh added a commit that referenced this issue Oct 23, 2024
This adds a check during `init` that will prevent Kong from starting if
any filter chain entities are found in the database using a filter that
is not installed. Example:

> Error: ./kong/cmd/start.lua:99: nginx: [error] init_by_lua error: /path/to/kong/init.lua:750: [wasm]: found one or more filter chain entities with filters that are not enabled/installed:
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #1 (response_transformer)
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #3 (response_transformer)

Previously, this condition would not be caught until the Wasm state is
built during `init_worker`. This change brings Wasm more in line with the
behavior of the plugins iterator.
locao pushed a commit that referenced this issue Oct 23, 2024
This adds a check during `init` that will prevent Kong from starting if
any filter chain entities are found in the database using a filter that
is not installed. Example:

> Error: ./kong/cmd/start.lua:99: nginx: [error] init_by_lua error: /path/to/kong/init.lua:750: [wasm]: found one or more filter chain entities with filters that are not enabled/installed:
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #1 (response_transformer)
> filter chain: 9e0b56d6-0e8c-469f-bf15-142debdd5d05, filter: #3 (response_transformer)

Previously, this condition would not be caught until the Wasm state is
built during `init_worker`. This change brings Wasm more in line with the
behavior of the plugins iterator.
flrgh added a commit that referenced this issue Nov 26, 2024
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 added a commit that referenced this issue Nov 26, 2024
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 issue Nov 27, 2024
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants