This message was deleted.
# general
a
This message was deleted.
p
according to this https://github.com/etcd-io/etcd/issues/13509 , its a failsafe and you should "just" remove your node from the cluster and join it back in.
c
This was during a rancher upgrade, the data directory was not lost or cleared. Not sure if this is the same issue.
p
Rancher upgrades are known to be rather... unpredictable. It wouldnt surprise me that you did nothing wrong but something still exploded somewhere.
👍 1
c
We've been using Rancher since 1.9, and have never had an issue with upgrading Rancher itself. So, we've never seen the claim of them being unpredictable.
p
Lucky you. I lost a week due to this bug https://github.com/rancher/rancher/issues/47102
c
This is not a bug, it's a known thing that nodes are not supposed to have their IPs change. https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements#node-ip-addresses
p
I did not intend the container to change its IP and nowhere in the UI did i get warned about something being explicitely wrong. Only part complaining was fleet, deep inside the local cluster
c
I shared the link to the page where it states that the IP address of nodes must not change, so it does warn you about it in the docs. You seemed to have done a very out of the ordinary task, your steps to reproduce would not have been a every day task, so extremely difficult to test such a non-standard setup.