RFC: Add support for optional runtime hint using network options

[mcastelino]

docker supports alternate OCI runtimes including virtual machine based runtimes. In certian cases network plugins can optionally choose to support creation of virtual machine friendly interfaces using optional network options.

This is illustrated here with the hint being used by the macvlan driver to create a macvtap interface vs a macvlan interface when the runtime is known to be a VM based runtime.

docker run --runtime=cor -it --net=pub_net --network "name=pub_net,runtime=namespace" alpine sh

This is currently based off of
moby/moby#27638

However this will be implemented as per the proposal
moby/moby#31964

The drawback of this approach is that the runtime and the endpoint runtime type have to be specified twice. However this approach may work better with containerd, where I assume the namespace and interfaces will be created prior to the launch of the container, and there is no prehook involved.

Ideally this could be done by extending the OCI specification pre-hook definition and sending that information to the network plugin.

// HookState is the payload provided to a hook on execution.
type HookState struct {
	Version string `json:"version"`
	ID      string `json:"id"`
	Pid     int    `json:"pid"`
	Root    string `json:"root"`
        Runtime string `json:"runtime"`
}

However that will not work consistently as the pre-hook is invoked after the EndpointCreate has occurred.
Some plugins create the interface at the time of Join and some at the time of Create.

Signed-off-by: Manohar Castelino [email protected]

[mcastelino]

To provide some more context: We are working with the upstream linux community to close the gaps for some interfaces. So providing the optional hint to the plugin, allows the plugin to make a choices around the type of interface to create. We do not mandate a tap interface per-se, but request for a VM friendly interface. However the VM runtime should not expect to always get a VM friendly interface

Here is an upstream patch set we are working on right now https://lkml.org/lkml/2017/1/25/665
This includes ipvlan tap: https://lkml.org/lkml/2017/1/6/844
And another part of the same patch set to makes tap a separate module for other types of virtual interface to use https://lkml.org/lkml/2017/1/25/664

Our goal is to provide the network plugins to ability make the right choices.

/cc @sainath14