Instead of moving the host side of the veth peer into the host
network namespace later, just create it in the host namespace
directly.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Controlling the mac address of the interface (veth peer) in the
container is useful for functionalities that depend on the mac address.
Examples range from dynamic IP allocations based on an identifier (the
mac) and up to firewall rules (e.g. no-mac-spoofing).
Enforcing a mac address at an early stage and not through a chained
plugin assures the configuration does not have wrong intermediate
configuration. This is especially critical when a dynamic IP may be
provided already in this period.
But it also has implications for future abilities that may land on the
bridge plugin, e.g. supporting no-mac-spoofing.
The field name used (`mac`) fits with other plugins which control the
mac address of the container interface.
The mac address may be specified through the following methods:
- CNI_ARGS
- Args
- RuntimeConfig [1]
The list is ordered by priority, from lowest to higher. The higher
priority method overrides any previous settings.
(e.g. if the mac is specified in RuntimeConfig, it will override any
specifications of the mac mentioned in CNI_ARGS or Args)
[1] To use RuntimeConfig, the network configuration should include the
`capabilities` field with `mac` specified (`"capabilities": {"mac": true}`).
Signed-off-by: Edward Haas <edwardh@redhat.com>
host-local and static ipam plugins
tuning, bandwidth and portmap meta plugins
Utility functions created for common PrevResult checking
Fix windows build
Namespace creation had an unergonomic interface and isn't used, except
for testing code. Remove it; downstream users should really be creating
their own namespaces
- start list of linux_only plugins; ignore them when testing on Windows
- Isolate linux-only code by filename suffix
- Remove stub (NotImplemented) functions
- other misc. fixes for Windows compatibility
* Wait for addresses to leave tentative state before setting routes
* Enable forwarding correctly
* Set up masquerading according to the active protocol
This change allows the host-local allocator to allocate multiple IPs.
This is intended to enable dual-stack, but is not limited to only two
subnets or separate address families.
Dan Williams