Now that we no longer use godeps to manage
dependencies we can safely remove this.
Dependencies in the vendor directory will
automagically be picked up.
This takes some of the machinery from CNI and from the rkt networking
code, and turns it into a library that can be linked into go apps.
Included is an example command-line application that uses the library,
called `cnitool`.
Other headline changes:
* Plugin exec'ing is factored out
The motivation here is to factor out the protocol for invoking
plugins. To that end, a generalisation of the code from api.go and
pkg/plugin/ipam.go goes into pkg/invoke/exec.go.
* Move argument-handling and conf-loading into public API
The fact that the arguments get turned into an environment for the
plugin is incidental to the API; so, provide a way of supplying them
as a struct or saying "just use the same arguments as I got" (the
latter is for IPAM plugins).
Path rewriting causes too many problems when vendoring
vendored code. When CNI code is vendored into rkt,
godep has problems code already vendored by CNI.
This introduces a notion of a "meta" plugin. A meta plugin
is one that delegates the actual work of setting up the interface
to the main plugin. The meta plugin is used to select and dynamically
configure the main plugin. The sequence of events, is as follows:
Given netconf like:
{
"name": "mynet",
"type": "flannel",
"delegate": {
"type": "bridge"
}
}
flannel fills in values like "mtu", "ipam.subnet" and delegates to
"bridge" main plugin. "bridge" plugin will operate as usual, calling
into ipam module for IP assignment.
Delegate dictionary should not contain "name" field as it will be
filled in by the flannel plugin.
This adds basic plugins.
"main" types: veth, bridge, macvlan
"ipam" type: host-local
The code has been ported over from github.com/coreos/rkt project
and adapted to fit the CNI spec.
