Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2011879

Summary: Rollback with eth interface connected to ovs-bridge fails
Product: Red Hat Enterprise Linux 8 Reporter: Radim Hrazdil <rhrazdil>
Component: nmstateAssignee: Gris Ge <fge>
Status: CLOSED WORKSFORME QA Contact: Mingyu Shi <mshi>
Severity: unspecified Docs Contact:
Priority: high    
Version: 8.4CC: ferferna, jiji, jishi, mshi, network-qe, till
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-02-24 13:07:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Radim Hrazdil 2021-10-07 15:22:41 UTC
Created attachment 1830414 [details]
logs

Created attachment 1830414 [details]
logs

Description of problem:

I'm hitting an issue with rollback failing after an nmstate desiredState failed to be applied.


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


How reproducible:
100% 

Steps to Reproduce:
1. Create ovs-bridge and connect eth0 to ovs-bridge, moving dynamic IP from eth0 to internal port:

interfaces:
- ipv4:
    dhcp: true
    enabled: true
  mac-address: 52:55:00:D1:55:02 # mac of eth0
  name: ovs0
  state: up
  type: ovs-interface
- bridge:
    options:
      stp: true
    port:
    - name: eth0
    - name: ovs0
  name: br114
  state: up
  type: ovs-bridge

2. Now remove the ovs-bridge and set enable eth0 again:
interfaces:
- ipv4:
    dhcp: true
    enabled: true
  name: eth0
  state: up
  type: ethernet
- name: ovs0
  state: absent
  type: ovs-interface
- name: br114
  state: absent
  type: ovs-bridge


Actual results:


The desired state in 2: __sometimes__ fails to be applied with the following nmstateverification error:
desired
=======
---
name: eth0
type: ethernet
state: up
ipv4:
  enabled: true
  address: [ ]
  auto-dns: true
  auto-gateway: true
  auto-routes: true
  dhcp: true

current
=======
---
name: eth0
type: ethernet
state: up
ipv4:
  enabled: true
  address:
  - ip: 192.168.66.102
    prefix-length: 24
ipv6:
  enabled: false
lldp:
  enabled: false
mac-address: 52:55:00:D1:55:02
mtu: 1500




When this happens, the rollback __always__ fails with the following error:

Async action: Rollback to checkpoint /org/freedesktop/NetworkManager/Checkpoint/82 started
2021-10-06 07:23:22,322 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/82 rollback executed
2021-10-06 07:23:22,323 root         DEBUG    Interface /org/freedesktop/NetworkManager/Devices/25 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface eth2 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface tunl0 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface /org/freedesktop/NetworkManager/Devices/26 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Async action: Waiting activation of eth0 ethernet started
2021-10-06 07:23:22,323 root         DEBUG    Interface eth0 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface lo rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface /org/freedesktop/NetworkManager/Devices/24 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface eth1 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface /org/freedesktop/NetworkManager/Devices/27 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Interface cali5759b335140 rollback succeeded
2021-10-06 07:23:22,323 root         DEBUG    Async action: Rollback to checkpoint /org/freedesktop/NetworkManager/Checkpoint/82 finished
2021-10-06 07:23:22,351 root         DEBUG    Active connection of device eth0 has been replaced
2021-10-06 07:23:22,352 root         ERROR    Rollback failed with error Waiting activation of eth0 ethernet failed: reason=<enum NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_DISCONNECTED of type NM.ActiveConnectionStateReason><enum NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED of type NM.DeviceStateReason>




I suspect that the rollback may fail because at the time eth0 is being activated to it's origianl state (which is connected to the ovs-bridge), the ovs-bridge is disconnected.


Expected results:


Additional info:
Relevant part of the log and a document with detailed description of the scenario is provided in the attached logs.

Comment 3 Gris Ge 2022-02-22 14:15:39 UTC
Hi Mingyu,

I failed to reproduce it NetworkManager-1.36.0-0.7.el8.x86_64, could you try again?

Comment 4 Gris Ge 2022-02-23 03:22:40 UTC
Sorry Mingyu, I should ask the reporter.

Hi Radim Hrazdil,

I failed to reproduce it with NetworkManager-1.36.0-0.7.el8.x86_64 and nmstate-1.2.1-1.el8 with 1000 try.

Could you try again?

Comment 5 Gris Ge 2022-02-24 13:07:17 UTC
This is not customer related issue and cannot reproduced in RHEL 8.6.

Will be tracked in upstream: https://github.com/nmstate/kubernetes-nmstate/pull/996

Reporter agreed the closure of this bug.