Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1860288

Summary:	[sriov] [4.4.z]VF cannot be inited when apply one policy if the 'default' policy is deleted and restored by operator
Product:	OpenShift Container Platform	Reporter:	zhaozhanqi <zzhao>
Component:	Networking	Assignee:	Peng Liu <pliu>
Networking sub component:	SR-IOV	QA Contact:	zhaozhanqi <zzhao>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	medium
Priority:	high	CC:	bbennett, dosmith, markmc, openshift-bugzilla-robot, pliu
Version:	4.4
Target Milestone:	---
Target Release:	4.4.z
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1860286	Environment:
Last Closed:	2020-10-13 08:17:44 UTC	Type:	---
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:	1860286
Bug Blocks:

Description zhaozhanqi 2020-07-24 08:57:40 UTC

+++ This bug was initially created as a clone of Bug #1860286 +++

Description of problem:
After I deleted the 'default' sriovnetworknodepolicies and it will be restored by operator. then now I apply one policy. Found the VF cannot be inited. 

Version-Release number of selected component (if applicable):
4.5

How reproducible:


Steps to Reproduce:
1. install the sriov operator
2. Delete the 'default' policy
oc delete sriovnetworknodepolicies.sriovnetwork.openshift.io default
3. Check the 'default' is restored
 oc get sriovnetworknodepolicies.sriovnetwork.openshift.io

4. Apply one policy with below
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-netdevice
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  nicSelector:
    pfNames:
      - ens1f0
    rootDevices:
      - '0000:3b:00.0'
    vendor: '8086'
  nodeSelector:
    feature.node.kubernetes.io/sriov-capable: 'true'
  numVfs: 5
  priority: 99
  resourceName: intelnetdevice

5. waiting the sriov-device-plugin and sriov-cni pods become 'running' and configdaemon logs show 'setNodeStateStatus(): syncStatus: Succeeded, lastSyncError:"
6.  Check 'sriovnetworknodestates.sriovnetwork.openshift.io' of node
oc get sriovnetworknodestates.sriovnetwork.openshift.io -o yaml

Actual results:
step 6: no VF were inited successfully.

spec:
  dpConfigVersion: "1540830"
  interfaces:
  - name: ens1f0
    numVfs: 5
    pciAddress: 0000:3b:00.0
    vfGroups:
    - deviceType: netdevice
      policyName: intel-netdevice
      resourceName: intelnetdevice
      vfRange: 0-4
status:
  interfaces:
  - deviceID: "1521"
    driver: igb
    mtu: 1500
    name: eno1
    pciAddress: "0000:18:00.0"
    totalvfs: 7
    vendor: "8086"
  - deviceID: "1521"
    driver: igb
    mtu: 1500
    name: eno2
    pciAddress: "0000:18:00.1"
    totalvfs: 7
    vendor: "8086"
  - deviceID: "1521"
    driver: igb
    mtu: 1500
    name: eno3
    pciAddress: "0000:18:00.2"
    totalvfs: 7
    vendor: "8086"
  - deviceID: "1521"
    driver: igb
    mtu: 1500
    name: eno4
    pciAddress: "0000:18:00.3"
    totalvfs: 7
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 9200
    name: ens1f0
    pciAddress: 0000:3b:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens1f1
    pciAddress: 0000:3b:00.1
    totalvfs: 64


Expected results:

VF can be inited. 

Additional info:

Delete configdaemon pod and make it re-create can resolve this issue

Comment 1 Peng Liu 2020-09-02 06:07:54 UTC

*** Bug 1871681 has been marked as a duplicate of this bug. ***

Comment 7 zhaozhanqi 2020-10-10 11:30:36 UTC

Verified this bug on 4.4

Comment 9 errata-xmlrpc 2020-10-13 08:17:44 UTC

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 (OpenShift Container Platform 4.4.27 bug fix update), 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-2020:4063