Currently we use a static configuration largely inspired by the default config.
We have prepared for templating logic but don't use it yet.
Maybe we should not limit outselves to making specific parts / parameters dynamic. I think in terms of impact per effort it could be good idea to build a generic config override approach. A method that allows operators (not regular users?) to inject a complete, custom config document. Maybe via an optional ConfigMap?
I assume that in the long run different deployments will have to use somewhat different IMEX daemon config documents. (that assumption might be wrong).
When I write this, I come from the debugging perspective: having full control over the IMEX daemon config allows for efficient troubleshooting / debugging.
This should be advertised as an "you are on your own here" feature.
Another note: just to name two examples: for NETWORK_INTERFACE and BIND_INTERFACE_IP I am not certain if we can have a silver bullet approach.
Currently we use a static configuration largely inspired by the default config.
We have prepared for templating logic but don't use it yet.
Maybe we should not limit outselves to making specific parts / parameters dynamic. I think in terms of impact per effort it could be good idea to build a generic config override approach. A method that allows operators (not regular users?) to inject a complete, custom config document. Maybe via an optional ConfigMap?
I assume that in the long run different deployments will have to use somewhat different IMEX daemon config documents. (that assumption might be wrong).
When I write this, I come from the debugging perspective: having full control over the IMEX daemon config allows for efficient troubleshooting / debugging.
This should be advertised as an "you are on your own here" feature.
Another note: just to name two examples: for
NETWORK_INTERFACEandBIND_INTERFACE_IPI am not certain if we can have a silver bullet approach.