Bug 1983816 - kubernetes-nmstate conflict with default_connection
Summary: kubernetes-nmstate conflict with default_connection
Keywords:
Status: CLOSED DUPLICATE of bug 1982821
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.8
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Ben Nemec
QA Contact: Oleg Sher
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-19 20:46 UTC by Ben Nemec
Modified: 2021-07-20 14:21 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-20 14:21:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ben Nemec 2021-07-19 20:46:17 UTC
Description of problem: Running the kubernetes-nmstate e2e tests against a 4.8 cluster fails on "STEP: Resetting nics state primary up and secondaries down". The policy being applied looks like this:

interfaces:
- name: enp2s0
  state: up
  type: ethernet
- ipv4:
    enabled: false
  ipv6:
    enabled: false
  name: enp3s0
  state: down
  type: ethernet
- ipv4:
    enabled: false
  ipv6:
    enabled: false
  name: enp4s0
  state: down
  type: ethernet

It appears that after NMState brings the p3 and p4 interfaces down, the NetworkManager default "Wired Connection" brings them right back up. This can be seen in a log message from NM:

device (enp3s0): Activation: starting connection 'Wired Connection' (fb456b53-0552-4794-9200-7b080ed93aeb)

This essentially undoes the NMState changes and causes the tests to fail. While in some real-world cases this may not be a problem, just the fact that it fails the e2e tests is a significant issue as it makes it impossible for us to regularly test the operator.


Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. Deploy 4.8 cluster
2. Deploy kubernetes-nmstate on the cluster
3. Run kubernetes-nmstate e2e tests

Actual results: All tests fail because the setup step does not complete


Expected results: All tests pass

Comment 1 Ben Nemec 2021-07-19 20:55:16 UTC
I found a similar-sounding bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1896866

I don't know if that's a particularly good solution for us since we don't know the interfaces the user will want to manage ahead of time so writing udev rules is not a great fit, but it does cover some other options they tried that did not solve the problem.

Comment 2 Ben Nemec 2021-07-20 14:21:18 UTC
Oh shoot, I had already opened a bug for this. I'll copy the additional information I found over to that one.

*** This bug has been marked as a duplicate of bug 1982821 ***


Note You need to log in before you can comment on or make changes to this bug.