Best case it’s idempotent and doesn’t do anything if a cluster has already been initialized, but it would also need to be idempotent successive runs and changes in cluster membership on different hosts, otherwise I have to manage things with a kind of “cluster_init_node” variable

I’d also assume that if the init has been done on server 1 and server 2 has successfully joined, then server 3 could join by pointing at server 1 or 2?

I’m in the process of testing all these to make sure I understand potential failure scenarios but if someone could short circuit this or let me know there’s an easier way let me know

“oops someone ran cluster init accidentally on our production k3s rancher server cluster”

so yeah, once a etcd database has been initialized on a node, the --cluster-init argument is not needed. Technically neither is the --server argument on the other servers.

and yes, you can join a new node by pointing at any existing server

Might have some followups after later testing, appreciate it

I threw together a PR for the docs here based on your comments