Invalid calls to ufw when cms-client-bound-address contains IPv6

While chatting with Frode Nordahl, he suggested the following quick fix (that I have not tested):

diff --git a/src/lib/charm/openstack/ovn_central.py b/src/lib/charm/openstack/ovn_central.py
index d9cd65b..f5ba614 100644
--- a/src/lib/charm/openstack/ovn_central.py
+++ b/src/lib/charm/openstack/ovn_central.py
@@ -642,6 +642,7 @@ class BaseOVNCentralCharm(charms_openstack.charm.OpenStackCharm):
             _addrs = list(addrs or [])
             for port in ports:
                 for addr in _addrs:
+ addr = addr.replace('[', '').replace(']', '')
                     ch_ufw.modify_access(addr, port=port, proto='tcp',
                                          action='allow', prepend=True,
                                          comment=ufw_comment)

Thank you for reporting this issue.

There are multiple facets to the solution:

1) We need to ensure the on the wire relation protocol uses pure IPv4/IPv6 address strings so that the remote end is free to compose the data in any shape/form on their discretion.

The both good and bad news here is that the current implementation is broken, so that we do not need to worry about breaking any in the wild users when fixing the on the wire protocol as no one would be able to successfully use the charm when bound to a IPv6 space at the moment.

2) The interface code is used to render the on the wire data for use in configuration templates as well as arguments to command execution, we may need separate properties for representing the pure ipv6 address string and the ipv6 address string encapsulated in brackets (`[]`).

3) Functional testing.

The current automatic test gates do not provide IPv6 connectivity and we do have a few dependencies on other projects in order to reliably enable that.