Description of problem: When applying a `NodeNeworkConfigurationPolicy` to workers (e.g. creating a VLAN interface), if a worker is down during the application of the policy, after it comes up, the worker never gets the new NM configurations so the VLAN or bridge is never created. If anything is updated in the Policy, for example, updating the description and re-applying to the workers, then it will be applied to all the workers online, even the ones that never got the configuration before. How reproducible: Always Steps to Reproduce: 1. Install CNV Operator 2. Create a `NetworkConfigurationPolicy` creating a VLAN 3. Shutdown a worker 4. Apply policy & confirm new interface was created in the workers online 5. Bring up the worker that was shutdown 6. The new VLAN interface is never created Expected results: There should be a remediation cycle in the operator that validates the configuration is as expected.
This should be tackled in the current master on U/S that will be shipped in CNV 2.3. We will verify whether it is fixed of course.
(In reply to Petr Horáček from comment #1) > This should be tackled in the current master on U/S that will be shipped in > CNV 2.3. We will verify whether it is fixed of course. Based on the above, souldn't this bug move to MODIFIED or even ON_QA?
Hi, So I have try this manually with kubernetes-nmstate u/s master and ocp 4.4 and it's working fine, so we may need to upgrade CNV 2.2 version.
Also testing with cnv-2.2 kubernetes-nmstate version (0.13.0) is working fine @William Caban can you attach also the output of following commands ? oc get nncp -o yaml oc get nnce -o yaml oc logs -n openshift-cnv -l app=kubernetes-nmstate
This report is from OCP 4.3 w/CNV 2.2. We will reproduce and report.
I think I have being able to reproduce it with kubevirtci provvider ocp-4.3 and upstream cluster-network-addons-operator 0.23.0 After shutting down the worker and applying a vlan policy and starting it up again, the worker does not show any sign of applying the policy itself. Also I see an error at master trying to re-apply the vlan (and nmstate failing, I susspect maybe is not idempotent there). Let's wait for your report so we check if we see the same issue. Also upgraded CNAO to 0.26.0 and everyting works fine.
ALso tested with CNAO 0.25.0 (That's the CNV 2.3 version) everything works fine, looks like this bug is fixed at CNV 2.3.
operatorVersion: v0.26.1
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/RHEA-2020:2011
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days