Wiki -> https://fedoraproject.org/wiki/Changes/EnableConsistentDeviceNamingCloud

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.


= Enable Consistent Device Naming in Cloud Images =

== 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. This change brings Fedora Cloud
in line with Fedora Server, Workstation, and CoreOS.

== Owner ==
* Name: [[User:mhayden|Major Hayden]]
* Email: ma...@redhat.com


== Detailed Description ==
Fedora cloud images currently set `net.ifnames=0` on the kernel
command line during the
[https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_35
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
[https://access.redhat.com/solutions/2435891|strongly 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. 
[https://lists.ubuntu.com/archives/ubuntu-devel/2016-April/039325.html|
Ubuntu] removed it in 2016, Debian
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863385| added it
back in 2017], and
[https://documentation.suse.com/sles/15-SP4/pdf/article-minimal-vm_en.pdf|
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
[https://github.com/canonical/cloud-init/blob/d8e3a4b4d4ca443227bf06bdaa5d9b47bd84e326/cloudinit/net/__init__.py#L480-L491|
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. This is especially important for
certain clouds, such as OpenStack clouds.

== Scope ==
* Proposal owners:

* Other developers:

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

* 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 ==

Users who don't need to apply any specialized network configuration
will likely not notice a change. All of the cloud-init functionality
will work the same as it did previously.

For users who need to apply specific network configuration on specific
instances will need to change the name they use to refer to those
network interfaces. For example, the main network device may shift
from `eth0` to `ens3` on some KVM platforms. Other cloud instances
might show a network device that specifies a PCI bus entry, such as
`enp2s0f0`. Although this might be confusing at first glance, it will
be familiar to users of Fedora Workstation, Server, and CoreOS.

Users could opt out by adding `net.ifnames=0` back to their kernel command line:

    grubby --update-kernel=ALL --args="net.ifnames=0"

== Dependencies ==

This change does not depend on any other changes and it has no impact
on cloud-specific dependencies, such as cloud-init.

If users have custom setup scripts that apply network configuration,
or if they use Terraform/Ansible to perform these steps, they may need
to adjust their scripts to account for the new network names.

== 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 ==

-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to