Relationship between Endpoints, SandboxInfos and Interfaces...

[tomwilkie]

As the interface & datamodel currently stands, Endpoints can be created via the libcontainer public interface Network, and contain a reference to a SandboxInfo. These SandboxInfo's hold references to a list of Interfaces. When creating a new Endpoint, the current bridge driver always creates a fresh SandboxInfo, and always populates this a single Interfaces.

The datamodel implies an endpoint can have multiple Interfaces, I don't understand why - is this intentional? Is the intention that these SandboxInfos should be shared in some way?

I'm also assuming we want to support container being connected to multiple networks, across potentially different drivers. Each driver will potentially want to offer different default gateways and nameservers, but it is only meaningful to have a single default gateway per container, and its typically only meaningful to have a single nameserver provider (You can have multiple nameserver, but only for redundancy - the OS doesn't query them unless their is a failure, not a negative response, AFAIU).

Given this, when starting a container the behaviour around which default gateway to choose, and which nameserver to insert, is currently undefined.

Is my understanding correct? Could you please clarify how this is suppose to be used?

Thanks

Tom

[mrjana]

@tomwilkie SandboxInfo is not an object that libnetwork data model actively manages. It's just a container of network resources allocated for a particular endpoint and we just return these info to the caller when they create an Endpoint. But we keep a copy of the SandboxInfo for the Endpoint within libnetwork so that libnetwork knows at all times what network resources are bound to which Endpoint

The reason why we have Interfaces slice in SandboxInfo is that Endpoint doesn't equate to Interface one-to-one. This is the same for a Network as well i.e a Network in CNM model doesn't have to equate to a single bridge in a driver one-to-one. If a driver chooses it can create multiple Interfaces and connect them to different virtual or physical networks(note this not the same network as we refer to in CNM) and control traffic to these different interfaces using different routes. Also it should be noted that the SandboxInfo will be enhanced in the near future with routes/iptables/tc policies etc.

Yes CNM allows multiple endpoints from the same container to connect to different networks(the CNM Network) and we are thinking of introducing certain driver generic config to the Endpoint. One of them could possibly indicate whether this is a primary or a secondary endpoint in the container. This hasn't been completely discussed yet so please take it FWIW.

[squaremo]

So @mrjana let me try to paraphrase what you've said.

• SandboxInfo is a "value object" that exists just to be the return value of CreateEndpoint and record the OS-level network configuration of an endpoint. It's not intended to be mutated after it's returned.
• A driver implementation may create more than one interface, so SandboxInfo has a field typed []Interface among others.

Questions:

• Does anything act on the information given in SandboxInfo, other than to print it out?
• Hence or otherwise, why does libnetwork need to retain SandboxInfo?
• If the purpose is to inform the driver of its own state when it's restarted, wouldn't it be better to let it supply its own, generic state value (e.g., a map[string]interface{})?

[squaremo]

NB I think the way libnetwork stands now will require a change in libcontainer similar to that @tomwilkie gives in #41 (comment)

[mrjana]

@squaremo SandboxInfo returned is in fact used by the libnetwork to create a sandbox. Please take a look at libnetwork/sandbox package and my answer to your queries in issue #41

[squaremo]

Please feel free to close this -- I think the relations among those things are clear (if not necessarily what we would have chosen), and the specific question about what happens with multiple endpoints is asked in #103.