I have confirmed this, it errors out as Dominique explained, unless 'prefer-ipv6' option is selected - in that case the percona won't start as it won't parse ipv6 addresses properly.
This only manifests when host is ipv6 only - in case of mixed ipv4/ipv6 setup the dns.resolver.query won't error out and the configuration will be properly created.
However, this all can be mitigated with using IPs instead of hostnames, in a manner that percona configuration (specifically the 'wsrep_cluster_address' option) always lists ip addresses with port numbers, like this:
That way the parser will first read the last colon, take the string right of it as a port number and then string right of it as the ip address (regardless of it being ipv4 or ipv6).
With this we don't need percona-cluster charm putting hostnames in configuration and adding those hostnames to /etc/hosts to make sure hostnames are properly resolved.
I have confirmed this, it errors out as Dominique explained, unless 'prefer-ipv6' option is selected - in that case the percona won't start as it won't parse ipv6 addresses properly.
This only manifests when host is ipv6 only - in case of mixed ipv4/ipv6 setup the dns.resolver.query won't error out and the configuration will be properly created.
However, this all can be mitigated with using IPs instead of hostnames, in a manner that percona configuration (specifically the 'wsrep_ cluster_ address' option) always lists ip addresses with port numbers, like this:
wsrep_cluster_ address= gcomm:/ /a1:b1: c1:d1:4567, a2:b2:c2: d2:4567
That way the parser will first read the last colon, take the string right of it as a port number and then string right of it as the ip address (regardless of it being ipv4 or ipv6).
With this we don't need percona-cluster charm putting hostnames in configuration and adding those hostnames to /etc/hosts to make sure hostnames are properly resolved.