Consider moving to a file based config

[onedr0p]

Keeping up with IaC, do you think it would be wise to move to this method of config instead of flags in the systemd service?

This is only supported in v1.19+ and would be breaking change. Maybe then is a good time to lock the 1.x release of this role and create a 2.x release that only supports k3s 1.19+

https://rancher.com/docs/k3s/latest/en/installation/install-options/#configuration-file

[onedr0p]

Do you also think that this would eliminate the need to have separate key names? We could build the config.yaml from a parent key (k3s_server/k3s_agent) and dump the children objects in the config.yaml file, e.g...

k3s_release_version: v1.19
k3s_github_url: https://github.com/rancher/k3s
...

k3s_server:
  write-kubeconfig-mode: "0644"
  tls-san:
  - "foo.local"
  node-label:
  - "foo=bar"
  - "something=amazing"
k3s_agent:
  write-kubeconfig-mode: "0644"
  tls-san:
  - "foo.local"
  node-label:
  - "foo=bar"
  - "something=amazing"

I think that would be pretty awesome, it would make maintenance on this role 1000x easier but validation might be still needed.

[xanmanning]

Yes, possibly. It would make it easier, though I might consider holding off until 1.19 is in the "stable" channel?

[onedr0p]

I thought 1.19 was in the stable channel, only that the embedded etcd part was experimental?

Edit: Whoops This issue is tracking marking it as stable

k3s-io/k3s#2265

[xanmanning]

Yep, hopefully not long.

[xanmanning]

Just a heads up @onedr0p , I'm going to use the V2 release as an excuse to set the minimum supported version of Ansible to >=2.10 as I will be using FQCNs.

I will continue to support the v1 role for a while but I will be pushing a note in the README to say v2 is Ansible >=2.10 with k3s >=1.19, and v1 is Ansible >=2.7 <=2.9 with k3s support <=1.19.

Some small overlap but I'd like to draw a line as conveniently both Ansible and k3s have made some big changes at roughly the same time.

I'm working on v2 and I'm a bit behind schedule, however I need k3s v1.19 to be in the stable channel before I release.

[onedr0p]

That's understandable @xanmanning this is a good idea.

[xanmanning]

Hit a snag... not sure if it's just me...

ansible/ansible#72319

EDIT: Not just me. I can release by not using FQCN for set_fact when k3s v1.19 hits stable channel. I'll try not let the obsessive part of me get annoyed about it.

[xanmanning]

k3s v1.19.3+k3s2 marked as stable

k3s-io/k3s#2487

Backport of ansible/ansible#71824 to Ansible 2.10 awaiting review.

ansible/ansible#72457

[xanmanning]

v2.0.0 has now been Released !

File based config is the main feature of this release. 🙂

[onedr0p]

Good work @xanmanning !