-
Notifications
You must be signed in to change notification settings - Fork 434
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
Severity of missing plugins #788
Comments
Hi @fxedel , Our philosophy is that you should test everything locally before pushing it to production, and plugin testing should be part of your CI/CD pipeline (pre-running it). Nevertheless, your input is valuable, and we will definitely take action. We are thinking of facilitating the offline testing of plugins (not in runtime - which must be superfast) so you can know before deploying a new KrakenD configuration that the plugins are loadable. This will probably be implemented as a new Krakend subcommand that you will add to your pipeline (as you do with In addition we will change the severity and messaging of the logs, so problems are easier to find. Some work has started: luraproject/lura#703 Thank you |
Hi @alombarte, thanks for your reply! Having a dedicated command to check plugin loading sounds like a good idea (although I don't really understood why KrakenD is even allowed to start if a plugin cannot be loaded, instead of failing fast) and the increased log levels definitely help very much at debugging. Thanks! |
Version of KrakenD you are using
Is your feature request related to a problem? Please describe.
More an anecdote than a problem: I recently tried to deploy krakend + my custom Go plugin on a machine. Krakend was running successfully and I could query my endpoints, but the response was not as expected. As it turned out, my plugin was not loaded due to some differences in the compilation environment (I set a custom
GOMODCACHE
, which is not possible when developing krakend plugins). However, it took me some time to find that out, since most relevant log messages were on the debug level and I'm using the info level on production.Describe the solution you'd like
I don't know by which extent the current behavior is desired, which would make sense if plugins were expected to be optional and it should not matter that much if they are loaded or not. In my understanding, though, missing plugins can lead to severe bugs, as the functionality of the API gateway is not fully guaranteed. When using security-relevant plugins, you want to be 100% sure that this plugin is loaded and running. I would argue that warning or failing on missing plugins adheres to krakend's architectural design principle "Failing fast is better than succeeding slow".
In particular, there are several steps about loading plugins that could be changed:
krakend-ce/plugin.go
Line 11 in ad15eb3
symbol HandlerRegisterer not found in plugin
, since it is completely valid for a plugin to not implement all three plugin types.pattern
should be updated), the binary's dependencies mismatch, or that the plugin is wrongly implement (i.e. wrong type ofHandlerRegisterer
). All of these cases should be fixed, and not (almost) silently ignored.RunServerFactory
or in particular the handler plugin'sNew
function: https://github.com/luraproject/lura/blob/v2.3.0/transport/http/server/plugin/server.go#L18:"plugin/http-server"."name"
configDescribe alternatives you've considered
The text was updated successfully, but these errors were encountered: