Comment 7 for bug 1848392

> I believe the new charm logic (using network_get) would work under the same circumstances.

I think there is still one edge case where the network_get logic would succeed while the existing logic would fail. Consider Vault on an instance with two networks, E and L, where E is external and bound to the "secrets" (or "secrets-external" if that's added). Then, the operator wants to make a CMR to K8s on network P which is an entirely different subnet from E but is routable to it (and P is not routable to L). In this case, the address from K8s over the relation will not match against either E or L since it is a address in P, whereas, since the "secrets" endpoint is explicitly bound to E, then network_get will return the right thing: the ingress-address in E. This was the case I was trying to cover in that PR, but I incorrectly assumed that Juju would be able to magically figure out which of E or L to return from network_get without an explicit binding where it obviously can't because of the rest of your comment.

Since the CMR doesn't imply any guarantee of connectivity between the units, I wonder if it would be reasonable to have the unit agents on either end of the relation perform some sort of "connectivity sanity check"? If we did that as part of the process of establishing the relation, then it could be rejected with a useful message to the operator, but I'm not sure that fits in with Juju's current process for establishing a relation. OTOH, if we had relation status, then Juju could report connectivity issues there, similar to reporting provisioning failures for machines.