Bug 1755586

Summary: [multus] Removing simpleMacvlanConfig from CNO not delete old network-attachment-definition
Product: OpenShift Container Platform Reporter: Weibin Liang <weliang>
Component: NetworkingAssignee: Tomofumi Hayashi <tohayash>
Networking sub component: openshift-sdn QA Contact: Weibin Liang <weliang>
Status: CLOSED CURRENTRELEASE Docs Contact:
Severity: medium    
Priority: unspecified CC: bbennett, nagrawal, tohayash
Version: 4.2.0Keywords: Reopened
Target Milestone: ---   
Target Release: 4.7.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: Not all related objects were deleted when the CNO was changed. Consequence: You would leave stale network-attachment-definitions. Fix: The code was refactored to do this in a more generic way in 4.3. Result: The related objects are cleaned up properly.
Story Points: ---
Clone Of:
: 1755908 (view as bug list) Environment:
Last Closed: 2020-10-22 13:03:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1755908    

Description Weibin Liang 2019-09-25 18:47:56 UTC
Description of problem:
Removing simpleMacvlanConfig from CNO not delete old network-attachment-definition

Version-Release number of selected component (if applicable):
4.2.0-0.nightly-2019-09-25-043501

How reproducible:
Always

Steps to Reproduce:
1. using simpleMacvlanConfig to create network-attach-def through CNO 
2. Check  network-attach-def is created
3. Edit CNO to remove simpleMacvlanConfig
4. After 21 minutes, network-attach-def is not deleted

Actual results:
[root@dhcp-41-193 FILE]# oc get networks.operator.openshift.io cluster -o yaml
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  creationTimestamp: "2019-09-25T14:51:10Z"
  generation: 8
  name: cluster
  resourceVersion: "57016"
  selfLink: /apis/operator.openshift.io/v1/networks/cluster
  uid: e9edd716-dfa3-11e9-adea-028a60c357e8
spec:
  additionalNetworks:
  - name: macvlan-ipam-static
    namespace: test1
    simpleMacvlanConfig:
      ipamConfig:
        staticIPAMConfig:
          addresses:
          - address: 22.2.2.2/24
            gateway: 22.2.2.254
        type: static
      master: ens5
      mode: bridge
    type: SimpleMacvlan
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  defaultNetwork:
    type: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
status: {}
[root@dhcp-41-193 FILE]# oc get network-attachment-definition --all-namespaces
NAMESPACE   NAME                  AGE
test1       macvlan-ipam-static   6s
[root@dhcp-41-193 FILE]# oc edit networks.operator.openshift.io cluster
network.operator.openshift.io/cluster edited
[root@dhcp-41-193 FILE]# oc get networks.operator.openshift.io cluster -o yaml
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  creationTimestamp: "2019-09-25T14:51:10Z"
  generation: 11
  name: cluster
  resourceVersion: "63895"
  selfLink: /apis/operator.openshift.io/v1/networks/cluster
  uid: e9edd716-dfa3-11e9-adea-028a60c357e8
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  defaultNetwork:
    type: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
status: {}
[root@dhcp-41-193 FILE]# oc get network-attachment-definition --all-namespaces
NAMESPACE   NAME                  AGE
test1       macvlan-ipam-static   5m59s
[root@dhcp-41-193 FILE]# oc get network-attachment-definition --all-namespaces
NAMESPACE   NAME                  AGE
test1       macvlan-ipam-static   21m

Expected results:
macvlan-ipam-static should be deleted

Additional info:

Comment 1 Casey Callendrello 2019-09-26 09:51:51 UTC
This is a known issue that will be fixed in 4.3 For the mean time, we should just fix this in the docs - you need to delete the resources manually.

Comment 2 Jason Boxman 2019-10-03 02:38:27 UTC
@Weibin

Does this affect `simpleMacvlanConfig` only, or does this apply to any `NetworkAttachmentDefinition` created and managed by the CNO?

Thanks!

Comment 3 Weibin Liang 2019-10-03 13:29:19 UTC
@Jason,

The bug does happen on both when configure `simpleMacvlanConfig` and any `NetworkAttachmentDefinition` created and managed by the CNO

Thanks,
Weibin

Comment 5 Ben Bennett 2019-12-04 14:23:48 UTC
This is fixed in a more general way in 4.3.  If we need a 4.2 backport, this can be the upstream bug.