-
Bug
-
Resolution: Unresolved
-
Normal
-
rhos-18.0.10 FR 3
-
None
-
3
-
False
-
-
False
-
?
-
Impediment
-
None
-
OSPK8S Sprint 7, OSPK8S Sprint 8, OSPK8S Sprint 9
-
3
-
Important
With the migration to using nad.EnsureNetworksAnnotation()
across all operators, we encountered issues when leveraging a specific feature of Multus CNI. This PR introduces a fix that ensures compatibility with that functionality and prevents errors that would otherwise occur.
The Multus Feature (NetworkAttachmentDefinition with CNI config file)
If NetworkAttachmentDefinition has no spec, multus find a file in defaultConfDir ('/etc/cni/multus/net.d', with same name in the 'name' field of CNI config.
# Execute following command at Kubernetes master cat <<EOF | kubectl create -f - apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: macvlan-conf-2 EOF
# Execute following commands at all Kubernetes nodes (i.e. master and minions) cat <<EOF > /etc/cni/multus/net.d/macvlan2.conf { "cniVersion": "0.3.0", "type": "macvlan", "name": "macvlan-conf-2", "master": "eth1", "mode": "bridge", "ipam": { "type": "host-local", "ranges": [ [ { "subnet": "11.10.0.0/16", "rangeStart": "11.10.1.20", "rangeEnd": "11.10.3.50" } ] ] } } EOF
The Issue
When using a config file–based Multus setup, the following error appears for all NAD-dependent operators:
failed create network annotation from <NAD(s)>: failed to unmarshal JSON data: unexpected end of JSON input"
This happens because the NAD spec may be empty. The proposed change adds a simple safeguard: it verifies that the NAD spec is not empty before attempting to parse it.
Github PR
I created the GitHub PR beforehand and just copied it's text above. Sorry if this is not the correct way you want to have the issues looking here. Is there any guide on creating issues for PRs?
GitHub PR: https://github.com/openstack-k8s-operators/lib-common/pull/636
- links to