Call first_master earlier and exclude from other_masters

[cwilhelm]

get first_master earlier and exclude it from other_masters #311

[sonarcloud[bot]]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[vitobotta]

Do you mind describing these changes a bit more? How do these solve the problem you highlighted in https://github.com/vitobotta/hetzner-k3s/issues/311 exactly?

I am not keen with introducing a "first master index" config setting" as it's brittle.

I think we can implement a more automatic recovery from this kind of scenario (first master deleted and replaced with a new one): when setting up a master which doesn't have the API responding yet, we can simply query the other masters and pick the token from the first one that responds to API calls.

So

• new cluster, no masters active: when setting up the first master no other masters will respond to API calls yet, so assume it's a new cluster and pick the first master as main
• new cluster, first master already active while we are setting up the other masters: we repeat the above for each master identically. In this case, since the first master is assumed to be active already when we set up master2 and master3, it will pick the token from master1
• existing cluster, first master replaced: again before setting up the replacement master, we query if other masters are responding to the API, if yes we pick the token from one of them and use that token to have the replacement first master join the others instead of initializing a new cluster.

WDYT?

[vitobotta]

Thanks again for the PR. I am closing because I handled this in a more robust way in https://github.com/vitobotta/hetzner-k3s/pull/348 for the upcoming new major version v2.0.0.