ADR 2: Config v2 #4920
ADR 2: Config v2 #4920
Conversation
Signed-off-by: Jussi Nummelin <[email protected]>
|
|
||
| ## Overview | ||
|
|
||
| This ADR is very high level proposal for the overall goals and high level aspirations for configuration v2. As such the puspose is not to go overly deep into where/how different fields are defined. |
There was a problem hiding this comment.
| This ADR is very high level proposal for the overall goals and high level aspirations for configuration v2. As such the puspose is not to go overly deep into where/how different fields are defined. | |
| This ADR is very high level proposal for the overall goals and high level aspirations for configuration v2. As such the purpose is not to go overly deep into where/how different fields are defined. |
|
|
||
| ## Context | ||
|
|
||
| The configration of k0s has organically growed from very small to something quite complex today. While that is natural we're starting to see growing number of issues stemmin from the complexity. |
There was a problem hiding this comment.
| The configration of k0s has organically growed from very small to something quite complex today. While that is natural we're starting to see growing number of issues stemmin from the complexity. | |
| The configuration of k0s has organically growed from very small to something quite complex today. While that is natural we're starting to see growing number of issues stemmin from the complexity. |
There was a problem hiding this comment.
| The configration of k0s has organically growed from very small to something quite complex today. While that is natural we're starting to see growing number of issues stemmin from the complexity. | |
| The configuration of k0s has organically grown from very small to something quite complex today. While that is natural we're starting to see growing number of issues stemming from the complexity. |
| - Config doesn't allow to disable components, it requires modifying the cmdline, specially with dynamic config, it would make sense to allow this from the configuration. | ||
| - In dynamicConfig it's not very straightforward what can and what cannot be modified | ||
|
|
||
| All of this results in confusions on both the uers side and also on maintainers. |
There was a problem hiding this comment.
| All of this results in confusions on both the uers side and also on maintainers. | |
| All of this results in confusions on both the user' side and also on maintainers. |
There was a problem hiding this comment.
| All of this results in confusions on both the uers side and also on maintainers. | |
| All of this results in confusions on both the user's side and also on maintainers. |
| foo: bar | ||
| ``` | ||
|
|
||
| Similarly we need to have config object for the workers. An example: |
There was a problem hiding this comment.
Is it proposed here that we will have one ControllerConfig for all Controllers and one WorkerConfig for all Workers ? Wouldn't be useful to have some kind of "label" matching so one could apply certain configuration just for some of their workers for instance ?
One use case I can imagine: some of my worker nodes have GPU and on those I want to setup containerd differently because reasons.
There was a problem hiding this comment.
Hi Ricardo,
No, the idea is that we have one ControllerConfig for each controller and one WorkerConfig for each worker and one ClusterConfig for the whole cluster.
We also discussed the need of having one way of having WorkerConfigs templates, it can be a field in the ClusterConfig spec or it can be a new object called WorkerGroup or something similar.
My understanding is that in the ADR we shouldn't be very explicit on whether it should be a new object or not, but now that you mention it we should probably document having worker templates/groups as a goal.
| - Dynamic config has several problems when it comes to reconciliation of certain fields | ||
| - Some fields have side effects that aren't very predictable. | ||
| - The k0s' configuration for calico doesn't really match the calico configuration | ||
| - Config doesn't allow to disable components, it requires modifying the cmdline, specially with dynamic config, it would make sense to allow this from the configuration. |
There was a problem hiding this comment.
| - Config doesn't allow to disable components, it requires modifying the cmdline, specially with dynamic config, it would make sense to allow this from the configuration. | |
| - Config doesn't allow users to to disable components - doing so requires modifying the cmdline. With dynamic config, it would make sense to allow this from the configuration. |
|
|
||
| ### Per node and cluster wide config separation | ||
|
|
||
| Separate the per node configuration and cluster-wide configs into their own CRDs. This makes it clear for both the users and maintainers where to look for which config data. It also makes clear separation on which _things_ can be changed at runtime via dynamic config. |
There was a problem hiding this comment.
It also makes clear separation on which things can be changed at runtime via dynamic config.
Does it actually make it clear which things can be changed and which cannot? Obviously changing helm chart extensions is allowed at runtime, and just as obviously changing the service CIDR range is not - but both would be part of the ClusterConfig, no?
|
The PR is marked as stale since no activity has been recorded in 30 days |
Description
Fixes # (issue)
Type of change
How Has This Been Tested?
Checklist: