How to distribute (release process) Kong? #2
Comments
|
easiest way for Debian packaging is to setup a ppa package through |
|
Package / Chef / Puppet / Docker / Vagrant (Not all at once, but eventually should support these) |
thibaultcha
changed the title
|
Take a look at the various Dockerfiles to see exactly what dependencies Kong needs. |
|
I'll just throw these in for consideration: |
|
👍 fpm, throw that in Travis, package it and store it back in github releases. |
|
also, github releases in itself is a distribution method, compile versions for different environments and store in github releases ... https://github.com/Mashape/kong/releases/tag/0.0.1-beta all can be done in Travis, with proper tagging and setup. |
|
We still need an environment-specific way to install on a server. Aka copy-paste of commands in an ssh session, using different package managers for dependencies. Putting stuff in GH releases doesn't really help, we are not shipping a binary, but a Luarocks module, so... It's install from source or Luarocks. |
|
When Niji suggested an installation shell script yesterday I remembered that's how Boundary supports a ton of platforms with the same quick installation snippet. Here's their script: https://github.com/boundary/boundary_scripts/blob/master/setup_meter.sh |
|
The problem with installation scripts is that you have to read it to know what it's going to do on your machine. When giving the user a list of commands feels safer and less time consuming (if you care about your setup). We could still provide the script for people who don't really care though. It is after all, suggested in the list above ^ |
|
only if you're extremely paranoid, 100% sure you don't read every brew ruby file, or every installation shell script you use. |
|
It's not about being paranoid, but knowing how and where it installs stuff. I know where my package managers install stuff. It's more about setup. And I understand better what it's doing, especially if we just have a .deb etc. We could replace an install.sh with a simple package manager |
|
Its actually fine, because it's in plain text so you can read what its doing 👍 |
|
I think we can close this issue for now. Install process has been discussed and is mocked. For release
In the future
|
Merged
thibaultcha
added a commit
that referenced
this issue
Dec 18, 2015
- Cluster is only spawned when inside if ngx_lua (when starting Kong). - Ensure LuaSocket is used by the driver by changing the return value of `ngx_stub.get_phase()` to `init`. - Ensure lua-cassandra does not output logs when in the `init` phase (which is the case because of change #2) and inside of the specs. Which is why `ngx.stub` is a new property.
windmgc
added a commit
that referenced
this issue
May 19, 2023
) This PR fixes a bug when worker consuming dynamic log level setting event and using a wrong reference for notice logging ``` 2023/05/18 14:29:06 [error] 23010#0: *3 [lua] callback.lua:98: do_handlerlist(): worker-events: event callback failed; source=debug, event=log_level, wid=0 error='./kong/runloop/handler.lua:937: bad argument #2 to 'log' (expected table to have __tostring metamethod) stack traceback: [C]: in function 'log' ./kong/runloop/handler.lua:937: in function <./kong/runloop/handler.lua:925> [C]: in function 'xpcall' ...uild/kong-dev/openresty/lualib/resty/events/callback.lua:83: in function 'do_handlerlist' ...uild/kong-dev/openresty/lualib/resty/events/callback.lua:130: in function 'do_event' .../build/kong-dev/openresty/lualib/resty/events/worker.lua:68: in function 'do_event' .../build/kong-dev/openresty/lualib/resty/events/worker.lua:239: in function <.../build/kong-dev/openresty/lualib/resty/events/worker.lua:221>', data={"timeout":60,"log_level":8}, context: ngx.timer ```
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 <aapo.talvensaari@gmail.com>
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 <aapo.talvensaari@gmail.com>
hanshuebner
pushed a commit
that referenced
this issue
Sep 26, 2023
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 <aapo.talvensaari@gmail.com>
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 <aapo.talvensaari@gmail.com>
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 <aapo.talvensaari@gmail.com> (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 <aapo.talvensaari@gmail.com> (cherry picked from commit dda623d)
3 tasks
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
3 tasks
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
ProBrian
pushed a commit
that referenced
this issue
Dec 13, 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
chronolaw
added a commit
that referenced
this issue
Dec 17, 2024
chronolaw
added a commit
that referenced
this issue
Dec 17, 2024
lhanjian
pushed a commit
that referenced
this issue
Dec 23, 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
Find a way to ship Kong and an easy way to install/run Cassandra for test purposes.
Ideas to experiment:
Things required to run Kong:
An idea could be that on the website, the user lands on a Download page asking him what is his distribution, he selects, we display the way to install Kong on his distribution (Deb vs RPM for example) as a list of commands he can copy/paste.
The text was updated successfully, but these errors were encountered: