Today, Multus will always log via STDERR, and these logs will then
logged by the Kubelet. If we also choose to have Multus log to a file by
setting the LogFile option in the CNI configuration, the same logs will
be logged twice.
This commit provide the option to disable logging to STDERR.
Signed-off-by: Yun Zhou <yunz@nvidia.com>
This PR updates the GitHub Actions workflows to build multus
container images for the IBM Z architecture (s390x), and also
adds daemonsets for s390x nodes.
entrypoint.sh uses python3 when it is available, since centos images
are not available for s390x, and python2 is not installed by default
on debian-based images.
Signed-off-by: Yohei Ueda <yohei@jp.ibm.com>
When we call mergeRuntimeConfig, the global RuntimeConfig gets
overwritten with the result of the merging, thus affecting the
subsequent delegates.
Do not modify the global RuntimeConfig and instead make a copy
when merging it.
Also, if a value has been provided for CNIDeviceInfoFile in the
delegate's runtimeconfig, overwrite it to avoid possible name
colissions.
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
entrypoint script fails with error when try reading capabilities in
non chain plugin config file when using "--multus-conf-file=auto"
Signed-off-by: Mamduh Alassi <mamduhala@mellanox.com>
Otherwise, this can cause a pod to not be fully deleted, its sandbox may remain as the DEL continues to be retried due to exiting non-zero every time.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1900835
NetworkStatus was moved to network-attachment-definition-client in previous
merges and the Multus version of the structure was left behind, and not
being used.
Signed-off-by: Billy McFall <22157057+Billy99@users.noreply.github.com>
DPDeviceFile is used by Device Plugins to pass device data to CNIs, as defined
in the device-info-spec. The name of the DPDeviceFile is defined by the
device-info-spec as:
<ResourceName>-<DeviceID>-device.json
If the DPDeviceFile exists, the NPWG implementation makes a copy of the file
and passes the name of the file to the delegate CNI via capabilityArgs as
CNIDeviceFile. If the DPDeviceFile does not exist, the filename is still
passed to the CNI. The CNI can create the file and popluate it if a device
is created within the CNI.
The name of the CNIDeviceFile is not defined by device-info-spec, but to
ensure the name does not clash it is formed by the following unique triplet:
[networkName, PodUUID, ifName]
k8snetworkplumbingwg/network-attachment-definition-client repo has utility
functions to abstract some of this functionality so it can be reused across
Device Plugins, NPWG implementations and CNIs.
Signed-off-by: Billy McFall <22157057+Billy99@users.noreply.github.com>
RuntimeConfig depends on the delegate configuration. The Netconf runtime
information should be merged with the delegate config and the result
added to each command that is sent to the delegates. That was being done
for all commands except for delPlugins.
Do not export MergeCNIRuntimeConfig and call it from
CreateCNIRuntimeConf that now accepts a delegate ptr.
Call it from delPlugins for each delegate
Signed-off-by: Billy McFall <22157057+Billy99@users.noreply.github.com>
Move Multus to use latest network-attachment-definition-client repo which
contains the device-info-spec changes.
Signed-off-by: Billy McFall <22157057+Billy99@users.noreply.github.com>
it can happen that a CNI Add operation is canceled because the
runtime sends a CNI Del too fast, so the pod was already deleted
when multus try to set the network status annotations.
Since multus is an executable and can not persist state, it can't
track the CNI requests that are done in parallel, but it can
assume that, if it was able to get the pod from the API, and in a
subsequent request the pod no longer exists, it is because it was
deleted.
Signed-off-by: Antonio Ojea <aojea@redhat.com>
