Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: add possibility to use net.naming-scheme #1215

Merged
merged 3 commits into from
Nov 7, 2024

Conversation

MichalHe
Copy link
Member

@MichalHe MichalHe commented Apr 29, 2024

Leapp writes .link files to prevent interfaces being renamed
after booting to post-upgrade system. This patch adds a less
error-prone approach that uses net.naming-scheme kernel param.
The naming-scheme tells udev what hardware properties to use
when composing a device name. Moreover, possible values of this
parameter are coarse-grained "profiles", that tell udev to
behave as if it did on RHEL8.0.

The functionality is enabled by setting LEAPP_USE_NET_NAMING_SCHEME
environmental variable to 1. If the feature is enabled, the .link
file generation is disabled. A kernel parameter net.naming-scheme=
is added to the upgrade boot entry and the post-upgrade entry.
The value of the parameter will be rhel-<source_major>.0. Note
that the minor source version is not used. Using also source major
version instead of 0 causes the device names to change slightly,
so we use 0. Moreover, an extra RPM named rhel-net-naming-sysattrs
is installed to the target system and target userspace container.
The RPM provides definitions of the "profiles" for net.naming-scheme.

The feature is available only for 8>9 and higher. Attempting to
upgrade 7>8 with LEAPP_USE_NET_NAMING_SCHEME=1 will ignore
the value of LEAPP_USE_NET_NAMING_SCHEME.

Add a possibility to use the net.naming-scheme cmdline argument
to make immutable network interface names during the upgrade.
The feature can be used only for 8>9 upgrades and higher.
To enable the feature, use LEAPP_USE_NET_NAMING_SCHEME=1.

Jira-ref: RHEL-23473

Copy link

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

  • review please @oamg/developers to notify leapp developers of the review request
  • /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp, e.g. from PR#42, use /packit test oamg/leapp#42
Note that first time contributors cannot run tests automatically - they will be started by a reviewer.

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

  • /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
  • /packit test --labels beaker-minimal-8.10to9.4,kernel-rt-8.10to9.4 to schedule kernel-rt and beaker-minimal test sets for 8.10->9.4 upgrade path

See other labels for particular jobs defined in the .packit.yaml file.

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

@MichalHe MichalHe force-pushed the use_net_naming_schemes branch 4 times, most recently from 4ca08f4 to 65cc048 Compare May 1, 2024 21:24
@pirat89 pirat89 added the enhancement New feature or request label May 2, 2024
@pirat89 pirat89 added this to the 8.10/9.5 milestone May 2, 2024
@MichalHe MichalHe force-pushed the use_net_naming_schemes branch from 65cc048 to e4abe9e Compare June 4, 2024 09:19
@pirat89 pirat89 modified the milestones: 8.10/9.5, 8.10/9.6 Jul 2, 2024
@MichalHe MichalHe marked this pull request as ready for review September 2, 2024 20:02
@MichalHe
Copy link
Member Author

MichalHe commented Sep 2, 2024

I have tested the PR using a rhel8 system running on real HW with a NIC that would be renamed during the upgrade. The solutions installed the rhel-net-naming-sysattrs package to the target system, the NIC names were consistent, and the post-upgrade system was booted with net.naming-scheme=rhel-8.10.

@MichalHe MichalHe force-pushed the use_net_naming_schemes branch from 496d59b to 1d04bf9 Compare September 2, 2024 20:06
Copy link
Member

@matejmatuska matejmatuska left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-wise seems okay, just some minor comments.

I know RHEL7 is EOL, but maybe you could check if the LEAPP_USE_NET_NAMING_SCHEME envar is set for 7->8 upgrade. I would expect at least a warning message in the logs, since we can't and won't do what the user explicitly wants.

I haven't tested the code yet.

@matejmatuska
Copy link
Member

/packit copr-build

@MichalHe
Copy link
Member Author

/packit build

@matejmatuska
Copy link
Member

/packit retest-failed

@matejmatuska
Copy link
Member

Tested, now works as expected.

PLease rebase and resolved conflicts.

@MichalHe MichalHe force-pushed the use_net_naming_schemes branch from 9f96f17 to 6a32159 Compare October 22, 2024 20:34
@MichalHe
Copy link
Member Author

@matejmatuska rebased

Leapp writes .link files to prevent interfaces being renamed
after booting to post-upgrade system. This patch adds a less
error-prone approach that uses net.naming-scheme kernel param.
The naming-scheme tells udev what hardware properties to use
when composing a device name. Moreover, possible values of this
parameter are coarse-grained "profiles", that tell udev to
behave as if it did on RHEL8.0.

The functionality is enabled by setting LEAPP_USE_NET_NAMING_SCHEME
environmental variable to 1. If the feature is enabled, the .link
file generation is disabled. A kernel parameter `net.naming-scheme=`
is added to the upgrade boot entry and the post-upgrade entry.
The value of the parameter will be `rhel-<source_major>.0`. Note
that the minor source version is *not used*. Using also source major
version instead of 0 causes the device names to change slightly,
so we use 0. Moreover, an extra RPM named `rhel-net-naming-sysattrs`
is installed to the target system and target userspace container.
The RPM provides definitions of the "profiles" for net.naming-scheme.

The feature is available only for 8>9 and higher. Attempting to
upgrade 7>8 with LEAPP_USE_NET_NAMING_SCHEME=1 will ignore
the value of LEAPP_USE_NET_NAMING_SCHEME.

Add a possibility to use the net.naming-scheme cmdline argument
to make immutable network interface names during the upgrade.
The feature can be used only for 8>9 upgrades and higher.
To enable the feature, use LEAPP_USE_NET_NAMING_SCHEME=1.

Jira-ref: RHEL-23473
@pirat89
Copy link
Member

pirat89 commented Nov 5, 2024

/packit copr-build

@MichalHe MichalHe force-pushed the use_net_naming_schemes branch from b82a1cd to a209d46 Compare November 6, 2024 21:34
Copy link
Member

@matejmatuska matejmatuska left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now this is only going to be enabled on 8->9.

The persistentnamesconfig actor is now properly skipped on paths other than 8->9 and emit_net_naming_scheme only emits on 8->9.
I tested it and it works as expected. LGTM

@matejmatuska matejmatuska merged commit e43a892 into oamg:main Nov 7, 2024
26 checks passed
@matejmatuska matejmatuska added the changelog-checked The merger/reviewer checked the changelog draft document and updated it when relevant label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog-checked The merger/reviewer checked the changelog draft document and updated it when relevant enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants