as discussed in slack i've written down my thoughts on a more dynamic config and what it could be good for to open the discussion. depending on the inputs i'd be happy to research more.
as more and more setups use cluster orchestration frameworks (such as e.g. kubernetes), h2o makes an excellent candidate for a loadbalancer / ingress controler. however in this type of setup, whenever a new new service is deployed the loadbalancer needs to be quickly updated to reflect new setups. Typical cases are new hostnames/TLS certificates, new upstream proxy backends or draining/disabling certain routes. In an ideal scenario some of the changes could be applied directly in a way so that all new connections are immediately affected.
also the current configuration should be readable from outside, so that automatic checks can ensure certain parameters.
one simple use case is supporting ACME or similar APIs to request and update TLS certificates. it would improve usability enormously if, for firing up TLS server all that was needed would be enabling some ruby code and adding the correct parameters into the config.
currently the only way to archieve this is by externaly updating the yaml config and then sending SIGHUP. this is clumsy as you need a second process or side container to handle this. in h2o's case, if the config would be accessible via mruby this would be much easier.
after some brainstorming i came up with the following use cases that could be enabled by this:
- implemeting acme directly in mruby in a much cleaner and better way than via external processes (e.g. kube-lego)
- implementing sophisticated API management platforms that leverage built in h2o features without the need to run mruby for all requests
- clustering solutions and e.g. reading config from distributed config systems such as etcd
- self updating config, where you have a default mruby handler that checks/enforces a few things and then (given a 200 response from the backend) adds the actual path as a configured route.
- similar to above you could implement a caching layer where mruby gets/saves the assets (would additionally need a TTL on a route).
- possibly much faster reloads and e.g. dynamic update of per session/per request things like logging directives
- and in general it would very much simplify scripting tasks from outside since not a full config needs to be written
- cloud plugins where external people would manage the config or you could plugin parts of the config. this is especially interesting if you could add/load/update mruby libraries.
the problem with this is that it would likely benefit from a rewritten config layer and/OR extra api to access the runtime config. a few points that come to mind:
- ability to arbitrary add annotations into the yaml that can be used by other systems, plugins, compile time plugins or mruby
- more flexibility in where to read the config from (file, http, mruby code)
- better error reporting for config problems
one major concern will certainly be security. <TODO insert possible solutions / migitations>
this would need further research. one solution could even be to keep the legacy config and create a new interface that can be controlled by mruby only.
