Comment 2 for bug 1497527

This issue is specific to:

    percona-cluster configured using access-network
    related service with multiple remote units

its caused by the fact that currently, the shared-db relation uses a multi-hook execution conversation to negotiate access over the correct 'access-network' configuration; the problem occurs when multiple units are in the service related, as it looks like the leader unit does not complete negotiation until after initial access (over 'private-address') has been granted, the follower units have negotiated correct access and the pxc charm has switched its db_host presented value over to a IP on the access-network, resulting in the leader trying to complete operations without the appropriate grants in place.

My proposed fix is to not present data until a valid ip is presented by each remote unit for access-network configurations; remote operations will continue to be gated by presence of the unit name in allowed_hosts, but this won't be present until the initial negotiation has completed.