Currently the k3s and k3s-agent are two separated blocks, which makes the configuration cumbersome and less intuitive.
The proposal is to switch away from two separate blocks, and streamline only one block that can be used for both.
For example, consider the current status quo:
k3s:
args: ..
k3s-agent:
args: ...
we could switch away to something more simple as:
k3s:
args: ..
server: true
So, instead of laying down both systemd settings, we could also generate them in runtime with the appropriate service, allowing the user full customization of how the k3s bins should run.
Action items
[ ] Merge k3s and k3s-agent blocks into k3s
[ ] Add an additional field to optionally discriminate between server and agent, otherwise fall back to all the config provided by the user
[ ] Optional: generate the services files in runtime. This might not be necessary at all, so at dev discretion
Currently the
k3s
andk3s-agent
are two separated blocks, which makes the configuration cumbersome and less intuitive.The proposal is to switch away from two separate blocks, and streamline only one block that can be used for both.
For example, consider the current status quo:
we could switch away to something more simple as:
So, instead of laying down both systemd settings, we could also generate them in runtime with the appropriate service, allowing the user full customization of how the k3s bins should run.
Action items
k3s
andk3s-agent
blocks intok3s