Andrey Smirnov
Andrey Smirnov
hmmm... it looks like etcd _joined_ something according to the logs
so I assumed there's something running
The only real problem I see in the log is that your control plane endpoint doesn't work.
even with Discovery Service TTL, it doesn't make much sense. during the upgrade, Talos controlplane node leaves etcd cluster, performs an upgrade, reboots and rejoins etcd back. In order to...
from the log above it looks like `etcd` is copying the data from other nodes, and it was still doing that after 30 seconds which is completely normal. `etcd` should...
so the root cause I guess is whatever makes etcd so slow to join the cluster.... (probably?) I don't have any specific idea about it. What you could do is...
not sure what exactly is wrong, but there's some membership issue with `etcd`. you might need to check `talosctl etcd members` on the healthy cp node according to the `etcd`...
In fact this file is in the `/boot` partition, so there are two ways to modify it: * mount the image and perform changes * modify RPi platform to accept...
Another idea which might be more robust is to use results of cluster discovery to support aliases like `:any_control_plane_node`, `:all_control_plane_nodes`, `:any_worker`, etc.
Cluster discovery works independent of the Kubernetes when discovery service is being used, so it works before the bootstrap.