Shared NIC: System doesn't retain the rate-limit config when a pod is deleted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
StarlingX |
Fix Released
|
Medium
|
Steven Webster |
Bug Description
Brief Description
-----------------
If an SR-IOV interface of type 'VF' has been configured with rate-limiting, eg:
system host-if-modify <host> <sriov_
And a VLAN is present in the network attachment definition, the rate limiting setting on the VF is removed when the pod is deleted.
ie. ip link show after launching pod:
...
vf 31 MAC 8a:1c:34:72:2a:df, vlan 2222, tx rate 200 (Mbps), max_tx_rate 200Mbps, spoof checking on, link-state auto, trust off
...
ip link show after deleting pod:
...
vf 31 MAC 8a:1c:34:72:2a:df, spoof checking on, link-state auto, trust off
...
Severity
--------
Major: System/Feature is usable but degraded
If a pod is launched which grabs the same VF that should be configured with rate-limiting, the traffic will no longer be rate-limited.
Steps to Reproduce
------------------
system host-if-modify <host> <sriov_
Create a network attachment definition with a VLAN configured:
apiVersion: "k8s.cni.
kind: NetworkAttachme
metadata:
name: sriov1
annotations:
k8s.
spec:
config: '{
"cniVersion": "0.3.0",
"type": "sriov",
"vlan": 2222
}'
Create a pod which uses the network attachment definition:
apiVersion: v1
kind: Pod
metadata:
name: pod1
annotations:
k8s.
{ "name": "sriov1" },
{ "name": "sriov1" }
]'
spec:
containers:
- name: appcntr1
image: centos/tools
imagePullPo
command: [ "/bin/bash", "-c", "--" ]
args: [ "while true; do sleep 300000; done;" ]
resources:
requests:
limits:
Expected Behavior
------------------
Rate limiting on the VF should be retained
Actual Behavior
----------------
Rate limiting configuration is removed
Reproducibility
---------------
100%
System Configuration
-------
Any
Branch/Pull Time/Commit
-------
02/17/2021 master
Last Pass
---------
N/A Note: The issue was not seen when a VLAN was not applied to the VF.
Test Activity
-------------
Feature Testing
Workaround
----------
Lock/Unlock the host
CVE References
Changed in starlingx: | |
status: | New → In Progress |
stx.5.0 / medium - found during testing of this stx.5.0 feature: https:/ /storyboard. openstack. org/#!/ story/2008470