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.
Created attachment 1788638[details]
log
Description of problem:
When creating a veth pair with nmstate, the local and the peer ifaces are both managed(even though you haven't explicitly listed the peer iface under `interfaces` key). But when changing the peer's name, the old peer is removed, while the new one is unmanaged.
Version-Release number of selected component (if applicable):
nmstate-1.1.0-0.1.el8.noarch
nispor-1.1.0-1.el8.x86_64
NetworkManager-1.32.0-0.4.el8.x86_64
How reproducible:
100%
Steps to Reproduce:
# At creation, both veth0 and veth0_ep are managed
echo "interfaces:
- name: veth0
type: veth
state: up
veth:
peer: veth0_ep" | nmstatectl apply -
# At changing, newpeer is created, unmanged
echo "interfaces:
- name: veth0
type: veth
state: up
veth:
peer: newpeer" | nmstatectl apply -
nmcli con
nmcli dev
# This is exactly same with the 1st step, but veth0_ep is managed
echo "interfaces:
- name: veth0
type: veth
state: up
veth:
peer: veth0_ep" | nmstatectl apply -
nmcli con
nmcli dev
Actual results:
The old peer is removed while the new one is unmanaged
Expected results:
IMHO:
1. Once created, the peer is not allowed to change
or
2. The peer can be changed and make the new one controlled automatically
or
3. Like #bz1932247 , in anytime, user should explicitly list peer iface under `interfaces` key, otherwise it won't been managed. It's not convenient but gives a consistent experience.
Additional info:
Verified with:
nmstate-2.2.1-1.el9.x86_64
NetworkManager-1.41.4-2.el9.x86_64
Linux dell-per740-80.rhts.eng.pek2.redhat.com 5.14.0-197.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 16 14:31:27 EST 2022 x86_64 x86_64 x86_64 GNU/Linux
DISTRO=RHEL-9.2.0-20221118.4
Nmstate removes the old veth pair, creates a new one and managed.
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 (nmstate bug fix and enhancement update), 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/RHBA-2023:2190