* Added hyperlink for logging
This may make it easier for users to find info on logging parameters since there isn't a dedicated docs page for it.
* Fixed hyperlink
Linked to proper section
* types: fix usage of strings.Split() for parsing CNI_ARGS
strings.Split() returns a slice, in this case with two elements of
the key and value. As such we shouldn't range over the slice when
the code is expecting a 2-element slice of key/value.
Otherwise we get errors for valid CNI_ARGS like:
2022-04-22T11:53:54Z [error] CreateCNIRuntimeConf: CNI_ARGS K8S_POD_NAMESPACE=openshift-etcd K8S_POD_NAMESPACE 17 is not recognized as CNI arg, skipped
2022-04-22T11:53:54Z [error] CreateCNIRuntimeConf: CNI_ARGS K8S_POD_NAMESPACE=openshift-etcd openshift-etcd 14 is not recognized as CNI arg, skipped
Fixes: d7d2a99ab5 ("Replace setenv with runtimeConfig set")
Signed-off-by: Dan Williams <dcbw@redhat.com>
* types/conf: fix handling of CNI_ARGS additions to rt.Args
We want to set the CNI_ARGS value in rt.Args if the existing value
is empty, not if the key doesn't exist yet. Since the rt.Args array
is pre-created with the K8S args keys, empty values of those keys
couldn't be overwritten with the previous scheme that just checked
if the key existed.
If the CNI_ARGS key wasn't found in rt.Args then add it; previously
a typo ("isExists != false") prevented that with inverted logic.
Signed-off-by: Dan Williams <dcbw@redhat.com>
* Added bash e2e test for static pods. Checks for net1 interface on pod.
Signed-off-by: nicklesimba <simha.nikhil@gmail.com>
* Enable static pod test in CI
Signed-off-by: nicklesimba <simha.nikhil@gmail.com>
* Addressed review comments
Signed-off-by: nicklesimba <simha.nikhil@gmail.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>
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>
