Bug 1798880

Summary: [RFE][sriov]should block user to create conflict vfRange
Product: OpenShift Container Platform Reporter: zhaozhanqi <zzhao>
Component: NetworkingAssignee: Peng Liu <pliu>
Networking sub component: SR-IOV QA Contact: zhaozhanqi <zzhao>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: fpaoline, sscheink
Version: 4.4   
Target Milestone: ---   
Target Release: 4.5.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-13 17:14:10 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:

Description zhaozhanqi 2020-02-06 08:30:02 UTC
Description of problem:
Set two conflict vfRange in 
ens1f0#1-4 --> SriovNetworkNodePolicy A
ens1f0#0-2 --> SriovNetworkNodePolicy B

those two CR can be created, it's not expected.

Version-Release number of selected component (if applicable):
quay.io/openshift-release-dev/ocp-v4.0-art-dev:v4.4.0-202002050701-ose-sriov-network-operator
quay.io/openshift-release-dev/ocp-v4.0-art-dev:v4.4.0-202002050701-ose-sriov-network-webhook
quay.io/openshift-release-dev/ocp-v4.0-art-dev:v4.4.0-202002050701-ose-sriov-network-config-daemon

How reproducible:
always

Steps to Reproduce:
1. Given the sriov operator is installed
2. Create the following two CR:
***********A********************
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-netdevice
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  nicSelector:
    pfNames:
      - ens1f0#1-4
    rootDevices:
      - '0000:3b:00.0'
    vendor: '8086'
  nodeSelector:
    feature.node.kubernetes.io/sriov-capable: 'true'
  priority: 99
  numVfs: 5
  resourceName: intelnetdevice
*************

********B********
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-netdevice2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  nicSelector:
    pfNames:
      - ens1f0#0-2
    rootDevices:
      - '0000:3b:00.0'
    vendor: '8086'
  nodeSelector:
    feature.node.kubernetes.io/sriov-capable: 'true'
  priority: 99
  numVfs: 5
  resourceName: intelnetdevice2
***************************
3. Check te sriovnetworknodestates 
oc get sriovnetworknodestates.sriovnetwork.openshift.io dell-per740-13.rhts.eng.pek2.redhat.com -o yaml 

4. check the resource num on node
# oc get node -o yaml | grep intelnetdevice
      openshift.io/intelnetdevice: "4"
      openshift.io/intelnetdevice2: "3"

Actual results:

step 3:

  dpConfigVersion: "764379"
  interfaces:
  - name: ens1f0
    numVfs: 5
    pciAddress: 0000:3b:00.0
    vfGroups:
    - deviceType: netdevice
      resourceName: intelnetdevice
      vfRange: 1-4
    - deviceType: netdevice
      resourceName: intelnetdevice2
      vfRange: 0-2

Expected results:

should block user create conflict vfRange.

Additional info:

Comment 1 Peng Liu 2020-02-11 07:37:06 UTC
To implement this feature, we need to do quite an amount of work in the webhook to check 1) the same NICs on the same Node is selected by different policies, 2) The vf ranges of the policies are conflicted. So I think it shall be an RFE for the operator webhook, maybe in 4.5.

Comment 6 zhaozhanqi 2020-04-27 12:29:49 UTC
verified this bug on 4.5.0-202004250717

Error message shown when create conflict range:

# oc create -f intel-netdevice.yaml
Error from server (Vf index range in ens1f0#1-4 is overlapped with existing policies): error when creating "intel-netdevice.yaml": admission webhook "operator-webhook.sriovnetwork.openshift.io" denied the request: Vf index range in ens1f0#1-4 is overlapped with existing policies

Comment 8 errata-xmlrpc 2020-07-13 17:14:10 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, 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:2409