Description of problem: A NetworkAttachmentDefinition without an empty spec.config can no longer be created. Version-Release number of selected component (if applicable): 4.2.something How reproducible: Always Steps to Reproduce: 1. Create the following NetworkAttachmentDefinition apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: my-nad namespace: myns Actual results: The API server rejects the creation with the following message: admission webhook "multus-validating-config.k8s.io" denied the request: network config is empty Expected results: Creating a NetworkAttachmentDefinition should still be possible, as it was in 4.1 Additional info: Multus allows creating an empty NetworkAttachmentDefinition. It then reads the config from a file with the same name as the net-attach-def (on the node's filesystem). This feature is still supported, but the admission controller erroneously doesn't allow it. OpenShift Service Mesh currently relies on this feature.
Ah, I mistyped the description. It should be: A NetworkAttachmentDefinition _with_ an empty spec.config can no longer be created
We have a downstream PR available for this one: https://github.com/openshift/multus-admission-controller/pull/10
Tested and verified in 4.2.0-0.nightly-2019-08-22-073746 [root@dhcp-41-193 Multus]# cat test.yaml apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: my-nad namespace: one-multus-interface [root@dhcp-41-193 Multus]# oc create -f test.yaml networkattachmentdefinition.k8s.cni.cncf.io/my-nad created [root@dhcp-41-193 Multus]# oc get network-attachment-definition NAME AGE macvlan-conf 6m40s my-nad 8s [root@dhcp-41-193 Multus]# oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.2.0-0.nightly-2019-08-22-073746 True False 41m Cluster version is 4.2.0-0.nightly-2019-08-22-073746 [root@dhcp-41-193 Multus]#
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2922