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.
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 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.
When plugin errors out, it prints out a JSON object to stdout
describing the failure. This object needs to be propagated out
through the plugins and to the container runtime. This change
also adds Print method to both the result and error structs
for easy serialization to stdout.
When plugin errors out, it prints out a JSON object to stdout
describing the failure. This object needs to be propagated out
through the plugins and to the container runtime. This change
also adds Print method to both the result and error structs
for easy serialization to stdout.
The plugin binary actually functions in two modes. The first mode
is a regular CNI plugin. The second mode (when stared with "daemon" arg)
runs a DHCP client daemon. When executed as a CNI plugin, it issues
an RPC request to the daemon for actual processing. The daemon is
required since a DHCP lease needs to be maintained by periodically
renewing it. One instance of the daemon can server arbitrary number
of containers/leases.
The plugin binary actually functions in two modes. The first mode
is a regular CNI plugin. The second mode (when stared with "daemon" arg)
runs a DHCP client daemon. When executed as a CNI plugin, it issues
an RPC request to the daemon for actual processing. The daemon is
required since a DHCP lease needs to be maintained by periodically
renewing it. One instance of the daemon can server arbitrary number
of containers/leases.
Add the ipvlan main plugin which is heavily based on the macvlan plugin.
Availabile modes for this plugin are l2 and l3, wheres l2 has the higher
compatibility due to support for multicast and broadcasts. L2 has therefore been
chosen as the default mode.
See the official docs at
https://www.kernel.org/doc/Documentation/networking/ipvlan.txt
for more information.
Fixes #6.
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.
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.
