Fix thick plugin daemonset to add volume mapping required for
sr-iov and fix code to update network status.
In addition, fix checkpoint structures to support K8s without
kubelet pod resources API.
fix#665 and #778
to prevent "unknown FS magic on "/var/run/netns/*": 1021994" errors
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Co-authored-by: Peter Hunt <pehunt@redhat.com>
* multus: entrypoint: disallow incompatible cni versions
When top level CNI version is 0.4.0 or more, nested CNI version
can't be less than 0.4.0 since these are incompatible. This
closes issue #737.
Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
* multus: thick: disallow incompatible cni versions
Similarly to disallowing incompatible versions in entrypoint.sh,
add the same logic in go for the thick plugin.
Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
* multus: add unit test for incompatible cni versions
Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
Co-authored-by: Balazs Nemeth <bnemeth@redhat.com>
This change make binary file and directory name consistent.
In addition, change the package name cni to server because cni
is a bit umbiguous for cni plugin's repository.
setenv refers environment variables, which is unique in process,
not unique to go routine. Hence it may causes some issue in multi
threaded case, hence it is replaced with libcni's runtimeConfig
value set to set these variables at libcni side, after process
fork.
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>
to prevent "unknown FS magic on "/var/run/netns/*": 1021994" errors
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Co-authored-by: Peter Hunt <pehunt@redhat.com>
* multus: entrypoint: disallow incompatible cni versions
When top level CNI version is 0.4.0 or more, nested CNI version
can't be less than 0.4.0 since these are incompatible. This
closes issue #737.
Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
* multus: thick: disallow incompatible cni versions
Similarly to disallowing incompatible versions in entrypoint.sh,
add the same logic in go for the thick plugin.
Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
* multus: add unit test for incompatible cni versions
Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
setenv refers environment variables, which is unique in process,
not unique to go routine. Hence it may causes some issue in multi
threaded case, hence it is replaced with libcni's runtimeConfig
value set to set these variables at libcni side, after process
fork.
Currently, the local workflow is far from optimal, since for every
change on the multus images the developers are required to redeploy
the kind cluster.
A more efficient workflow would be to build a local image, upload it to
the kind cluster, and finally re-deploy (delete & re-provision) the
daemonset, which would be running the new version.
For this flow to be possible, the multus container `imagePullPolicy`
must be set to `Always` - [0] - otherwise, the image is not updated.
[0] - https://kubernetes.io/docs/concepts/containers/images/#updating-images
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
To keep consistency between actual network and CNI result in cache,
update libcni cache when multus add/del default routes by
`default-route` network selection.
The test was just checking that a READ/WRITE fsnotify.Event for
the multus configuration was being seen; this patch changes this
behavior, and assures that the delegateCNI configuration update results
in turn on the update of the multus configuration file.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
Using a unique path for the config generation will lessen the
amount of events caught by the test that checks if the multus
configuration must be re-generated as a result a default cluster
configuration update.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
