This consumes the latest release of the network-attachment-definition-client
library which fixes a regression affecting CNI plugins that do not specify
interfaces in their CNI ADD result. This was fixed in [0].
[0] - https://github.com/k8snetworkplumbingwg/network-attachment-definition-client/pull/77
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
From the release notes:
> This release contains a fix related to the determination of the default interface, e.g. setting the default parameter to true in the network-status annotation based on the presence of a gateway in the CNI ADD success result ips.gateway and makes the determination of the default based on the first interface that has an associated value of gateway (using the interface index in the ips element in the CNI ADD success result).
> This provides flexibility especially in CRI-O which uses the first interface and IP addresses for the pod.IP in Kubernetes, therefore. Containerd functionality is unchanged in that it uses the value for the IP addresses specifically
> It's worth noting that CNI ADD success results which do not contain any interfaces will be discarded in this determination of the default, therefore it's recommended to set one with an associated gateway if aiming to have it be noted as the default.
See also:
https://github.com/k8snetworkplumbingwg/network-attachment-definition-client/releases/tag/v1.7.5https://github.com/k8snetworkplumbingwg/network-attachment-definition-client/pull/73
Previous version didn't account for accounts for the sandox interfaces when reporting the interfaces in the network-status annotation when calculating the default:true interface
This fixes the default:true for multiple interface returns from CNI for cluster default network, where all interfaces in that return were marked as default:true in the network-status
* This makes checking events a lot easier
* upgrade fsnotify package
Signed-off-by: yanggang <gang.yang@daocloud.io>
Signed-off-by: yanggang <gang.yang@daocloud.io>
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
Multus community decide that multus support the Kubernetes that
Kubernetes community supports, so changed vendor code to the
oldest version of currently supported.
The CRD is now defined in the NetworkPlumbingWG org, along with
generated libs for client, listers, informers, and deep copy functions.
Therefore remove the duplicate definition here, and use the standard
definition.
Signed-off-by: Tim Rozet <trozet@redhat.com>
* Improved coverage of checkpoint.go to 96.4%
* Improved coverage of checkpoint.go to 96.4%
* Fixed unit tests in checkpoint_test.go and conf_test.go
* Removed unnecessary comments
* improved conf code coverage by an amount that is greater than 0!
* improved coverage, but line 144 of conf.go needs a look
* Added unit tests to multus and types, also fixed a bug in conf.go
* increased code coverage in multus.go and conf.go, also added bug fixes and formatting
* hopefully resolved merge conflicts
* addressed all comments in review
* changed 'thejohn' to '_not_type' for readability
* Added network status annotations section to quickstart and added more unit tests
* added more tests to k8sclient.go
* added another test to k8sclient.go
* Added new function to testing.go and cleaned up tests
adding new imported package dependencies in vendor which is required
for Kubelet Pod Resource api client.
Change-Id: If6c74598e12af5f8659df69371e72dd064823f49
