An issue has come up where an application which is being offered via CMR has multiple network bindings available and the consuming application is on the subnet of the non-default binding but network-get for that relation ID still returns the info for the default binding, leading to the wrong address being advertised by the charm. If I understand it correctly, passing the --via option with the correct subnet to juju add-relation when establishing the CMR should resolve the issue, but I don’t understand why that’s necessary. Presumably, Juju can see if the consuming charm is not on the subnet of the default binding and could automatically select the appropriate binding when returning the network-get info. Why is this not done, or am I misunderstanding something about how network bindings and cross-model relations work?
Yeah, this does seem like a legitimate bug.
I haven’t digested the issue in detail, but the --via option is used when relating a consuming app to inform the offering side from where the traffic will originate so that any security/firewall rules etc can be correctly set on the offering end, eg postgresql sets up such rules in hba.conf. In network-get, --via affects the egress-subnets attribute.
@cory_fu can you please update the bug Ian created with details on the version used and if we’ve got a small test case that repro’s easy enough please? TY!