Include interface MTU in types.Result for Interfaces

[mcastelino]

Today the spec returns the name and mac of the interfaces. So we already include some L2 information.

// Interface contains values about the created interfaces
type Interface struct {
	Name    string `json:"name"`
	Mac     string `json:"mac,omitempty"`
	Sandbox string `json:"sandbox,omitempty"`
}

For VM based runtimes having the MTU would also be helpful.

So something along the lines of

// Interface contains values about the created interfaces
type Interface struct {
	Name    string `json:"name"`
	Mac     string `json:"mac,omitempty"`
	Mtu     int `json:"mtu,omitempty"`
	Sandbox string `json:"sandbox,omitempty"`
}

[leodotcloud]

Usually in the container world, the MTU is a setting of a network so it's driven from the runtime towards the plugins not the other way round. I am assuming it should be the same for VMs too? Can you please elaborate your use case @mcastelino?

[bboreham]

There are a thousand possible cases of "X would be helpful"; if we add all of them to the spec then we will end up with a JSON document that describes every possible networking option. And that is a non-goal of the project.

[rosenhouse]

Crazy idea: What if, instead of making a spec change for every X, we had a result field that was analogous to the args on the config struct. In other words, plugins could return an arbitrary bag of data to the runtime.

We could develop some conventions around that, which would be lighter weight than a spec change.

If a runtime wanted to get particular data about an interface, it could bundle and execute an "inspector" plugin that returned data of interest.

[mcastelino]

@rosenhouse @bboreham providing the ability for a plugin to return an arbitrary set of data would be helpful.

Also, what should be the convention be in the case where plugins are chained. Should they just append to the same set.