Our CI is currently mistakenly executing the thick img on the e2e
legacy lanes. Furthermore, the e2e daemonset spec provided features
(and uses) the kubeconfig / multus conf generation binaries
provided only on the thick image.
This commit addresses these by enabling the e2e `setup_cluster.sh`
script user to specify the path to the desired deployment
configuration.
Github workflows are updated accordingly.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* Update quickstart.md
removed unnecassary dollarsign since it kills the quick copy functionality of Code in Github
* Update README.md
* Update quickstart.md
* Update how-to-use.md
Co-authored-by: Doug Smith <douglaskippsmith@gmail.com>
This volume was removed since multus now requires the default cluster
network CNI configuration to be available. As such, the volume as
removed, but we unfortunately forgot to remove to remove the volume
mount.
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>
Because the tests fake out the OS exec functionality, the environment that
would usually be passed to a plugin instead gets passed as a string array
to the ExecPlugin() function in the tests. But when verifying the expected
environment this function was looking at the actual OS environment rather
than the passed string array. Fix that.
Use that to test various cases of the pod UID being passed to plugins.
Signed-off-by: Dan Williams <dcbw@redhat.com>
If the runtime passes a pod UID via K8S_POD_UID (which both CRIO and
containerd do as of mid-2021) then fail if the pod we get from the
Kube API has a different UID. This would indicate that the pod was
deleted and recreated while Multus was attempting to set up
networking for the old pod instance's sandbox, and it's pointless
to continue setting up a sandbox for a dead pod instance.
Also pass the pod UID through to plugins so they can perform
additional checking and validation on the pods they get from the
Kube API.
Signed-off-by: Dan Williams <dcbw@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.
Currently golang community supports 1.16 and later, hence, need
to update golang version in our build pipeline. This change
updates golang version to 1.17/1.16.
Thus not repeating ourselves, nor shadowing the global variables
that had the same name (pollInterval / pollTimeout).
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
Also retry on the following error types (cmd ADD/DEL):
- IsInternalError
- IsConnectionReset
- IsConnectionRefused
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
When configuring `clsuterNetwork` in Multus CNI config, the value
for `clusterNetwork` needs to match the value for `name` key in
the file `clusterNetwork` setting refers to. This condition is
undocumented in doc/configuration.md. This PR adds description
on the condition for users to understand `clusterNetwork` config
more clearly.
Signed-off-by: Sho SHIMIZU <sho.shimizu@gmail.com>
