Description of problem: An OCP UPI deployment of 4.6.12 is deployed. During the deployment a bond0 interface is configured along with a vlan sub interface bond0.vlan1. The deployment process places OVN br-ex bridge on that interface. After deployment attempted to apply an NNCP policy (see attached) that creates a second vlan sub interface bond0.vlan2 and a linux bridge br-ext. The policy fails to apply and from the logs it appears the reason is that nmstates tries to do something with br-ex even though its not in the configuration. Logs and configuration attached. Version-Release number of selected component (if applicable): CNV 2.5.3 OCP 4.6.12 NAME="Red Hat Enterprise Linux CoreOS" VERSION="46.82.202101131942-0" VERSION_ID="4.6" OPENSHIFT_VERSION="4.6" RHEL_VERSION="8.2" How reproducible: Unsure - Marius was going to try to reproduce. Customer can reproduce all day long Steps to Reproduce: 1.Install OCP via UPI with OVNKubernetes SDN 2.Install CNV 3.Attempt to apply NNCP policy Actual results: Policy fails to apply Expected results: Policy should apply Additional info:
This is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1913248 and https://bugzilla.redhat.com/show_bug.cgi?id=1913215, so it may require a similar solution. If I'm not mistaken, unlike the two bugs above, here the original setup is following (notice the extra VLAN iface below OVS bridge): [eth0]--[bond1]--[vlan10]--[OVS bridge] [eth1]-/ And the resired state is: [eth0]--[bond1]--[vlan10]--[OVS bridge] [eth1]-/ \---[vlan20]--[linux bridge] @Fernando, could you please take a look? And would it be possible to backport this fix to nmstate 0.2?
I tested this on my environment(same as in BZ#1913248) and I was unable to reproduce the issue as the NNCP got created successfully, though my env is slightly different as Petr mentioned: [enp5s0]--[bond0]--[OVS bridge] [enp6s0]-/ \---[vlan10]--[linux bridge]
(In reply to Petr Horáček from comment #4) > This is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1913248 and > https://bugzilla.redhat.com/show_bug.cgi?id=1913215, so it may require a > similar solution. > > If I'm not mistaken, unlike the two bugs above, here the original setup is > following (notice the extra VLAN iface below OVS bridge): > > [eth0]--[bond1]--[vlan10]--[OVS bridge] > [eth1]-/ > > And the resired state is: > > [eth0]--[bond1]--[vlan10]--[OVS bridge] > [eth1]-/ \---[vlan20]--[linux bridge] > > @Fernando, could you please take a look? And would it be possible to > backport this fix to nmstate 0.2? Hi! I will look into this. I would like to know if these interfaces are being created with Nmstate/NM or an external tool. The backports to 0.2 depends on the fix, I suspect this issue is already fixed on 0.3 or greater. If it is possible to fix it I will backport it. Thanks!
Fernando It was indicated that the customer is creating the initial bond0 and first sub vlan interface during the deployment process of OCP and it is during the deployment process that br-ex is attached to that setup. The customer then does a day 2 operation of trying to apply the nncp that is attached to the BZ.
We are unable to reproduce this with CNV. However, the fix to the described issue should be delivered in the latest nmstate. Thus skipping QE and closing.