Deployment Breaking: etcd charm fails to format ipv6 address correctly

[Alex Zero]

The etcd charm does not place square brackets around IPv6 addresses. This breaks IPv6 deployment (though I thought this was supposed to be supported as per the docs at https://ubuntu.com/kubernetes/docs/ipv6)

Jan 26 21:30:02 juju-ade073-kubernetes-2 etcd.etcd[20892]: Running as system with data in /var/snap/etcd/230
Jan 26 21:30:02 juju-ade073-kubernetes-2 etcd.etcd[20892]: Configuration from /var/snap/etcd/common/etcd.conf.yml
Jan 26 21:30:02 juju-ade073-kubernetes-2 etcd.etcd[20892]: unexpected error setting up initial-advertise-peer-urls: URL address does not have the form "host:port": https://2a10:4a80:407:1:f816:3eff:fe67:9826:2380

[George Kraft (cynerva)]

Can you tell us more about the environment this is running in? Does your etcd unit have an IPv4 address?

The charm is getting that address from Juju, which is a bit unexpected, since Juju itself does not fully support IPv6 and requires IPv4 on the underlying hosts. It's obvious that the charm is not handling the address well, but I need to figure out if there is a misconfigured environment or a Juju bug underlying this.

[Alex Zero (citadelcore)]

Hi - this is an OpenStack deployment with one network that has both an IPv4 subnet and an IPv6 subnet (SLAAC).

I have verified the units are getting both a v4 and v6 address. In Juju when I list all machines, the v6 address is shown as the primary, not the v4.

[George Kraft (cynerva)]

Thanks. It looks like the charm blindly picks the first address it receives from Juju via network-get. We'll see about getting that fixed.

It does seem a bit weird that the machines are showing with IPv6 primary address. I've added Juju as an affected project to weigh in. In a mixed IPv4/IPv6 OpenStack environment, is it expected for machines to show IPv6 addresses as their primary?

[Alex Zero (citadelcore)]

I'm not entirely sure. This is my first experience with Juju on OpenStack, and I haven't experienced it ever using IPv4 for the primary address. I'm not sure how the decision to prefer v6 over v4 is made, or if there's some way to override it in the controller config (I looked, but could not find anything).

[John A Meinel (jameinel)]

I'm not sure what is being considered the Juju bug in this place (hence the incomplete). Juju does support IPv6 for workloads, and does allow charms to interact with IPv6. (We have some deployments that are strictly IPv6.) I don't believe our modeling of dual-stack is great, but it is possible to have charms that support more than just IPv4.

[Alex Zero (citadelcore)]

I have removed the "affects" on Juju here as this is purely the fault of charm-etcd.

[George Kraft (cynerva)]

Also reported in https://bugs.launchpad.net/charm-etcd/+bug/1947034, in which Andrew shares a workaround (thanks!):

> As a quick fix, changing all entries of the ipv6 addresses in /var/snap/etcd/common/etcd.conf.yml to the correct ipv4 address for etcd up and running with a healthy peer.

[Adam Dyess (addyess)]

Attempting to address this with a PR:
https://github.com/charmed-kubernetes/layer-etcd/pull/208