Comment 11 for bug 1831580

This bug was hit again, this time during the deployment of a proof of concept, the characteristics of the scenario were the same: manual provider where etcd misbehaved due to the 127.0.0.1 getting registered as the ingress address and from that point all the services related to etcd were trying to use it.

On site the /etc/hosts was fixed, but it looks like etcd already stored the incorrect address calling set_db_ingress_address()[0] which internally calls to conversation.set_remote()[1] and that ultimately boils down to a relation-set[2]

[0] https://github.com/charmed-kubernetes/layer-etcd/blob/master/reactive/etcd.py#L242
[1] https://github.com/juju-solutions/interface-etcd/blob/master/peers.py#L57
[2] https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/relations.py#L773