Conventions: add convention around chaining interfaces

[squeed]

This is a change to CONVENTIONS that states, essentially, that plugins SHOULD be chained if at all possible. The intention is to support the widest-possible set of users.

[mcastelino]

@squeed does this mean in the case of #420 I should retain the veth functionality in the bridge plugin. Hence we do not need a special veth plugin, but just need a tap plugin?

Also when you have bridge+tap chained, who is responsible for invoking the IPAM plugin? Also in that case should the plugin chain be inverted. i.e. call tap followed by bridge?

[squeed]

@mcastelino Great questions
1 - We should probably make a veth plugin for completeness, but in the interest of both optimizing the most common case and preserving existing behavior, the bridge plugin should create a veth automatically
2 - The first plugin is always responsible for invoking ipam.

Make sense? Thanks!

[mcastelino]

@squeed makes sense. I will update #420 to continue to support veth setup in the bridge plugin. That will also allow the current unit tests to run successfully.

However even in this case I am still not sure how the IPAM can be assumed to called by the first plugin.
Consider the following case where we want to chain tap with the bridge plugin. As you see below the bridge plugin will continue to need IPAM specification in addition to the tap plugin. This will be needed as the veth component within the bridge will need the IPAM plugin.

If we update the spec to call out that the IPAM plugin can be repeated when chaining plugins, and how that should function should help clarify the relationship between the IPAM and invoking plugin.

{
        "cniVersion": "0.3.0",
        "name": "mynet",
        "plugins": [
        {
                "type": "tap",
                "ipam": {
                        "type": "host-local",
                        "subnet": "10.22.0.0/16",
                        "routes": [
                                { "dst": "0.0.0.0/0" }
                        ]
                }
        },
        {
                "type": "bridge",
                "bridge": "cni0",
                "isGateway": true,
                "ipMasq": true,
                "ipam": {
                        "type": "host-local",
                        "subnet": "10.22.0.0/16",
                        "routes": [
                                { "dst": "0.0.0.0/0" }
                        ]
                }
        }
        ]
}

[mcastelino]

@squeed Longer term we should consider the IPAM plugin to be chained vs embedded into the veth/tap plugin. This is required in the case where the IPAM is of type DHCP. Here the IPAM can only be invoked once the interface is connected to the bridge. So invoking the IPAM as part of the veth plugin will not work in the case where the chain is veth->bridge.

So the chain that would work is veth -> bridge -> ipam.
Here the new result information in version 0.3.0 passed through the plugin invocation sequence really helps.

I will rework my existing veth->bridge implementation to prototype the veth->bridge->ipam sequence and check if there are any gaps.

Also in the case of a VM based runtime and tap interfaces, the DHCP request needs to be initiated from within the VM. Hence splitting out the IPAM would make sense in that case too.

[dcbw]

@mcastelino agreed on the chaining behavior of veth -> bridge -> ipam; we discussed that in the maintainers meeting this week. If you can do the rework that would be awesome. Or is #420 already reworked in that way?

[dcbw]

LGTM

[bboreham]

LGTM

[tomdee]

LGTM