Roadmap

[ayr-ton]

Motivated on the discussion started here:
k3s-io/k3s-ansible#39 (comment)

Which direction do you folks see this repository taking for the future?

Do you have suggestions or bugs not reported as issues yet?

Have a PR in mind and want to discuss if it make sense as an issue?

Let's burst some contributions from this async discussion. :-)

[jon-stumpf]

I still need to finish my review of ansible-role-k3s. I am very familiar with k3s-ansible.

In k3s-ansible, I have submitted three, cumulative PRs but received no feedback from the maintainers:

• Fix omissions and errors in the reset role that leave artifacts after successful reset.yml playbook run k3s-io/k3s-ansible#158: made the reset playbook be at parity with https://get.k3s.io k3s-uninstall.sh
• Implemented many install flags as found in the install script from https://get.k3s.io k3s-io/k3s-ansible#164: implemented most of the install switches from https://get.k3s.io
• Finished k3s-ha implementation; Add three (3) cluster VIP methods implemented via ansible k3s-io/k3s-ansible#166: finished HA

In reviewing the issues and PRs, the two things that I would like to see implemented are:

1. WIP: add tests k3s-io/k3s-ansible#52
2. Added (airgap) images as part of the download role to provide full coverage of a k3s installation k3s-io/k3s-ansible#114

The rest I believe can be closed/cancelled (or I have implemented it already).

For ansible-role-k3s, I first intend to replace k3s-uninstall.sh and k3s-killall.sh with ansible equivalents (done in jon-stumpf/k3s-ansible). That will be my first pull request.

And, for the merger, I would like to get k3s-io to agree on hosting this repo.

[utkuozdemir]

A few things come to my mind:

• Testing upgrades from CI - I had a problem on upgrading from k3s v1.22.3+k3s1 to v1.22.4+k3s1 with this module. It was related to the certificates under /var/lib/rancher/k3s/server/tls. Didn't dig deep into it to give more details (since I stopped using it afterwards), but some additional testing can help here.

• Make the role do things more similar to other tools: I think it'd be beneficial to make the end state more similar to what k3s's own install.sh or k3sup does - same files at same locations with same content. Doing it might reduce the chances of something going wrong (example: maybe remove the soft-links hard-links thing)

• I had a problem with free strategy with nodes not respecting --node-ip and --node-external-ip args correctly. Again, I didn't dig deeper. If I have some time I can look into reproducing it and opening an issue. But overall, making sure that role works fine with free strategy can be a good idea (or if it doesn't work with free, document it and/or fail on preflight).