Before the real update orchestration happens we are updating etcd
certificates, so this machine isn't left isolated. However, in this
process, the configuration for etcd might refer to the new machine
names if this happens during the upgrade of 2.0 to 3.0. This might
leave the etcd instances in a state in which they cannot resolve
other etcd peer names (because their /etc/hosts file is outdated).
In order to prevent this, force the etc-hosts sls to be run before
we execute the etcd sls, so we are sure that /etc/hosts will
contain both the old and the new names during the upgrade, and etcd
will be able to refer to other peers using the new hostnames.
Before the real update orchestration happens we are updating etcd certificates, so this machine isn't left isolated. However, in this process, the configuration for etcd might refer to the new machine names if this happens during the upgrade of 2.0 to 3.0. This might leave the etcd instances in a state in which they cannot resolve other etcd peer names (because their
/etc/hostsfile is outdated).In order to prevent this, force the
etc-hostssls to be run before we execute theetcdsls, so we are sure that/etc/hostswill contain both the old and the new names during the upgrade, and etcd will be able to refer to other peers using the new hostnames.Fixes: bsc#1096750