In the context of CMR and bug Bug #1826892 “Add support for multiple API VIPs” : Bugs : vault-charm I think it is worthwhile to raise a design question of using a space binding per “relation id” or, in other words, supporting multiple bindings per endpoint.
An application may listen on 0.0.0.0 on a multi-interface host and, in case of TCP, connected sockets would be created on the actual interface IP addresses based on the IP that was present in a request. In order for a client to discover one of the IPs available on a host we use ingress-address propagated via relations to the client side.
For deployments with multiple network spaces the same endpoint in metadata.yaml might be desirable to use with bindings to different spaces (the use-case of the bug above).
Conceptually:
metadata.yaml portion of example-http-server
application:
bindings:
"": oam-space
# the first binding is the "primary" one for compatibility
http: oam-space,internal-space,public-space
Then at relation creation time one should be able to specify a space binding to use on both sides or the “primary” one would be used by default:
# public-space would be used for this relation
juju add-relation example-http-server:http:public-space example-http-client:http:public-space
# oam-space would be used by default at the example-http-server side
juju add-relation example-http-server:http example-http-client:http
From the implementation perspective:
network-get already supports -r relationid
argument and then passes it along to NetworkInfo API call.
At the apiserver side both in NetworkInfo and EnterScope NetworksForRelation is called where a bound space is retrieved either by calling GetSpaceForBinding or, if that fails, using a heuristic based on whether relation is cross-model or not.
So the idea would be to extend GetSpaceForBinding to support relationId-aware lookups for bindings and to extend the bundle syntax to support multiple bindings per endpoint with a “primary” binding per endpoint for compatibility.
Using additional endpoints in metadata.yaml is not very useful as they are not used for creating the actual relations (thus reviews for 1826892 use convoluted code to work around that).
Thanks in advance for any feedback!