From Fedora Project Wiki
Line 89: Line 89:


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.


Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
Use an image built without `net.ifnames=0` or take an existing cloud instance and remove `net.ifnames=0` from the kernel command line:


A good "how to test" should answer these four questions:
    grubby --update-kernel=current_kernel --remove-args="kernel_args"


0. What special hardware / data / etc. is needed (if any)?
After a reboot, the device names should change from `eth0` to reflect the consistent device names based on the hardware:
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


    $ ip link | grep ^[0-9]
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    2: enp2s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    4: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000


== User Experience ==
== User Experience ==

Revision as of 20:02, 18 March 2024

Enable Consistent Device Naming in Cloud Images

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

This proposal aims to remove the net.ifnames=0 kernel command line entry from the Fedora cloud kickstarts so that consistent device naming is enabled for cloud instances.

Owner

Current status

  • Targeted release: Fedora Linux 41
  • Last updated: 2024-03-18
  • [<will be assigned by the Wrangler> devel thread]
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Fedora cloud images currently set net.ifnames=0 on the kernel command line during the kickstart process. This disables consistent device naming and ensures that ethernet devices retain the old-style names of eth0, eth1, eth2, and so on.

Removing the net.ifnames=0 configuration allows Fedora cloud instances to use consistent device names for network devices. This brings Cloud images in line with Fedora Server, Workstation, and CoreOS.

Feedback

One of the proposed alternatives is to leave net.ifnames=0 in the kernel command line to remain consistent between releases. Although RHEL allows for net.ifnames=0 for KVM instances, it is recommended not to use it with OpenStack or RHV environments. Fedora Cloud images are used for multiple types of clouds, including public clouds and private clouds.

This approach is less disruptive, but it pushes off the consistent device naming change until a later date and causes cloud images to operate differently than other Fedora deployments.

Other distributions have taken different turns with this configuration. Ubuntu removed it in 2016, Debian added it back in 2017, and SUSE has had it for some time. There were issues with cloud-init during the early days of network device naming in 2016/2017, but cloud-init supports consistent network names since 2017. RHEL currently uses net.ifnames=0, but there is a debate about whether it should be removed in a future major release.

Benefit to Fedora

The main benefit comes from bringing cloud instances inline with other deployment types in how they name network devices. It also helps with cloud providers that offer up different types of network interfaces to an instance. For example, an emulated network device would present itself differently than one offered via SRIOV and it would allow an instance administrator to easily tell which network interface corresponds to each network device.

Scope

  • Proposal owners:
  • Other developers:
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

Upgrade/compatibility impact

Upgrades: Users who are upgrading to the next Fedora release will not notice a change in their instances since the net.ifnames=0 change is only applied during the kickstart process. Their instances will continue using the old network names.

New deployments: If a user has older Fedora deployments and they deploy a new Fedora release with this change applied, their network devices will use consistent network names instead of the old eth0 and eth1 style names. Although this won't impact software like cloud-init, it will impact users who have deployment scripts (Terraform or Ansible, for example) that need to set network configuration based on the network adapter's name. They will need to adjust the name of the network device in their deployment scripts.

How To Test

Use an image built without net.ifnames=0 or take an existing cloud instance and remove net.ifnames=0 from the kernel command line:

   grubby --update-kernel=current_kernel --remove-args="kernel_args"

After a reboot, the device names should change from eth0 to reflect the consistent device names based on the hardware:

   $ ip link | grep ^[0-9]
   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
   2: enp2s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
   3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
   4: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000

User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No


Documentation

N/A (not a System Wide Change)

Release Notes