-
Bug
-
Resolution: Not a Bug
-
Major
-
None
-
4.15
-
-
-
Important
-
No
-
ShiftStack Sprint 250
-
1
-
Rejected
-
False
-
Description of problem:
Deployment of an SR-IOV/DPDK MachineSet fails creating ports due to securityGroups failure.
The MachineSets configurations are according to the official documentation. [0]
$ oc get events -n openshift-machine-api | grep Failed
96s Warning Failedcreateport machine/ostest-9b6s2-worker-1-4m2wr Failed to create port ostest-9b6s2-worker-1-4m2wr-dpdk_net_nic0_9_normal_worker-1_port: Bad request with: [POST http://10.46.96.71:9696/v2.0/ports], error message: {"NeutronError": {"type": "PortSecurityAndIPRequiredForSecurityGroups", "message": "Port security must be enabled and port must have an IP address in order to use security groups.", "detail": ""}}
Version-Release number of selected component (if applicable):
OCP 4.15.0-0.nightly-2024-02-21-222537 on top of RHOS-17.1-RHEL-9-20240123.n.1. IPI telco env.
How reproducible:
Always
Steps to Reproduce:
1. Install OSP for Telco env
2. Deploy a OCP cluster with no workers using IPI method
3. Create SR-IOV/DPDK MachineSets according to https://docs.openshift.com/container-platform/4.15/machine_management/creating_machinesets/creating-machineset-osp.html#machineset-yaml-osp-sr-iov_creating-machineset-osp
Actual results:
The machine creation is stuck on "Provisioning" due to PortSecurityAndIPRequiredForSecurityGroups:
```
96s Warning Failedcreateport machine/ostest-9b6s2-worker-1-4m2wr Failed to create port ostest-9b6s2-worker-1-4m2wr-dpdk_net_nic0_9_normal_worker-1_port: Bad request with: [POST http://10.46.96.71:9696/v2.0/ports], error message: {"NeutronError": {"type": "PortSecurityAndIPRequiredForSecurityGroups", "message": "Port security must be enabled and port must have an IP address in order to use security groups.", "detail": ""}}
```
Expected results:
The machine and node are up after applying the MachineSet config
Additional info:
1. We had a similar bug with LB - https://issues.redhat.com/browse/OCPBUGS-22246 2. If we are removing the securityGroups config from the MachineSet, the failure is not reproduced, and the node comes up
