refactor: modularize everything, separate files and new submodules

[aleksasiriski]

• Switch to MPLv2
• Refactor variables into separated files with better code structure
• Refactor locals into separated files with better code structure
• Refactor network, lb, cni, csi, etc. into new submodules
• Combine configs for control_planes, agents and autoscaler nodes
• Move bash scripts inlined within Terraform into files that are called by Terraform
• Consider dropping support for unused options, they will still be available with example Helm charts
• Pin versions of everything and create CI to bump up versions when they come out
• Improve CI/CD pipeline, with added tests and possibly real testing on Hetzner before merging to main
• Autogenerating documentation using quality comments in the source code
• Create example configs for most common usecases of the project (small, medium and large cluster deployment)
• Consider creating website documentation
• Create a script for converting old TF to new TF

Maybe more...

[maggie44]

Could we add pinning of all dependency versions and bumping as PRs to the list as mentioned here? https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner/pull/1206/files#r1497072303

I think pinned versions is a good default for production. Not all of the dependent packages are built like OpenSuse where it’s designed for rolling updates. It would relate to the CI which would then run tests against new minor and major bumps.

[aleksasiriski]

Could we add pinning of all dependency versions and bumping as PRs to the list as mentioned here? https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner/pull/1206/files#r1497072303

I think pinned versions is a good default for production. Not all of the dependent packages are built like OpenSuse where it’s designed for rolling updates. It would relate to the CI which would then run tests against new minor and major bumps.

I wholeheartedly agree, if you want you can make a PR to this PR with that fix or I will do it when I get the free time again.

[BuddhiAbeyratneAL]

Im not a lawyer but from what I've seen in practice

MIT to MPL2 can't be a direct swap.
one has a copy left ish clause that people have to comply with
Also the old code needs to continue to distribute as MIT even if you pull it out as submodules

[aleksasiriski]

Im not a lawyer but from what I've seen in practice

MIT to MPL2 can't be a direct swap. one has a copy left ish clause that people have to comply with Also the old code needs to continue to distribute as MIT even if you pull it out as submodules

You are correct, this won't be merged until all contributors agree to it. We will be creating a poll to accomodate that.