-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Comments
@thefosk
Attaching an application to an
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?
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';
TODOWe should start replacing the controllers code with the new DAO, as the main features are now finished. |
Note for me Monday:
Then just need to finish updating the controllers code. |
We need a way to distinguish server errors from client errors in the DAO. Cassandra error != Non existing FOREIGN key or failing UNIQUE check |
The easiest solution I can think of is a response like: local res, err, client_err, server_err = dao:do_something() By having both 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. |
Or 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 } } |
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? |
@thibaultcha the only problem that I see with your solutions (and with my last one, with the |
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"
}
|
@thibaultcha so what is the conclusion? |
|
Excuse me? |
At this point the DAO is finished and the refactor TODOs are now moved to #12 |
) ### 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 ```
### 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]>
### 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]>
### 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]>
### 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]>
### 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]>
### 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]>
### 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)
### 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)
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]>
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]>
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]>
…olicy_securityScan_120-google.golang.org/grpc_1.39.0 Upgrade dependency
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.
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.
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.
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.
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
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
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
type
)immutable
property for values that cannot be updatedThe text was updated successfully, but these errors were encountered: