Currently we have a single config package.
It breaks the SDK first principle. It's not possible to inject config when you implement an extension of the proxy.
Also it leads to a lot of conflicts. If the config changes in one feature, and another feature also edits it, it all breaks.
We need to apply similar registry pattern that will allow constructing config from different parts. Similar to how it works in dotnet, where you can define the key for config class and it will be deserialized from the config.
It can be implemented by using a custom unmarshaler in koanf.
The packages themselves must define the configs and register them under specific keys. It's important to remember that we might have proxy, upstream or tool level configs.
We also need to update the operator types and CRD generation. It MUST work after the refactoring. People must be able to extend the proxy CRDs with their configurations if they extend our proxy.
Currently we have a single config package.
It breaks the SDK first principle. It's not possible to inject config when you implement an extension of the proxy.
Also it leads to a lot of conflicts. If the config changes in one feature, and another feature also edits it, it all breaks.
We need to apply similar registry pattern that will allow constructing config from different parts. Similar to how it works in dotnet, where you can define the key for config class and it will be deserialized from the config.
It can be implemented by using a custom unmarshaler in koanf.
The packages themselves must define the configs and register them under specific keys. It's important to remember that we might have proxy, upstream or tool level configs.
We also need to update the operator types and CRD generation. It MUST work after the refactoring. People must be able to extend the proxy CRDs with their configurations if they extend our proxy.