On Wed, Jan 5, 2022 at 9:52 AM David Cantrell <dcantrell@xxxxxxxxxx> wrote: > > On Wed, Jan 05, 2022 at 09:22:20AM -0500, Neal Gompa wrote: > >On Wed, Jan 5, 2022 at 9:11 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > >> > >> On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > >> > > >> > On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > >> > > > >> > > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles > >> > > > >> > > == Summary == > >> > > Do not not include NetworkManager support for legacy network > >> > > configuration files by in new installations. > >> > > > >> > > == Owner == > >> > > * Name: [[User:Lkundrak| Lubomir Rintel]] > >> > > * Email: <lkundrak@xxxxx> > >> > > > >> > > * Name: Ana Cabral > >> > > * Email: <acabral@xxxxxxxxxx> > >> > > > >> > > * Name: [[User:Thaller| Thomas Haller]] > >> > > * Email: <thaller@xxxxxxxxxx> > >> > > > >> > > == Detailed Description == > >> > > Long ago, network was configured using "network" service. > >> > > It was essentially a set of shell scripts, that sourced snippets of > >> > > configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg > >> > > files"). > >> > > The ifcfg files compatible with the legacy network service were kept > >> > > when NetworkManager was intruduced. > >> > > > >> > > As the NetworkManager feature set was expanding beyond what the legacy > >> > > network service could support, > >> > > the ifcfg files written by NetworkManager could no longer be > >> > > guarranteed to be compatible. > >> > > NetworkManager eventually gained support for connection types > >> > > completely unknown to the legacy network service > >> > > and ended up using a more streamlined configuration file format for > >> > > those, known as keyfile. > >> > > > >> > > NetworkManager's use of various configuration files is, in fact, > >> > > configurable and extensible with plugins. > >> > > Prior to Fedora 33, NetworkManager by default was configured to enable > >> > > both ifcfg files and keyfiles, with the former taking precedence when > >> > > possible. > >> > > The precedence changed in > >> > > [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh > >> > > Fedora 33] to perfer keyfile. > >> > > > >> > > The precedence has an effect when a network connection profile is created. > >> > > Once the connection profile exists, NetworkManager is unable to > >> > > convert the profile to a different configuration backend. > >> > > This makes it necessary for NetworkManager to support the same feature > >> > > set in all configuration backend. > >> > > Given the complexities stemming from historical legacy of ifcfg files > >> > > not being designed (or documented) in a > >> > > particularly forward-looking way, this has been a huge and complex > >> > > effort with all the downsides: > >> > > The ifcfg support code is huge (130K lines, not counting the enormous > >> > > test suite) and has constantly been a source of bugs. > >> > > > >> > > == Benefit to Fedora == > >> > > This change removes a body of code that has a large cost in terms of > >> > > bugs and maintenance at questionable benefit. > >> > > > >> > > It slightly reduces the default installation size. > >> > > > >> > > == Scope == > >> > > * Proposal owners: Split the ifcfg plugin into a subpackage package. > >> > > Make sure the ifcfg plugin stays on upgrades. Provide a migration > >> > > tool. > >> > > > >> > > * Other developers: N/A > >> > > > >> > > * Release engineering: N/A > >> > > > >> > > * Policies and guidelines: N/A > >> > > > >> > > * Trademark approval: N/A > >> > > > >> > > * Alignment with Objectives: N/A > >> > > > >> > > == Upgrade/compatibility impact == > >> > > For the time being the ifcfg plugin is kept around, albeit in a > >> > > sub-package that's not included in new installations. > >> > > The appropriate RPM tags will ensure the sub-package with the ifcfg > >> > > plugin will be installed on upgrades. > >> > > A migration tool will be provided for users who'd like to remove the > >> > > legacy package from their systems after upgrade. > >> > > > >> > > == How To Test == > >> > > N/A. > >> > > The keyfiles are used by default in Fedora 33 already, so any problem > >> > > with them would've already been spotted. > >> > > > >> > > == User Experience == > >> > > Regular users will not notice anything. > >> > > Users of old installations with ifcfg files will get the new > >> > > sub-package on upgrade. > >> > > New systems will default to use keyfiles, which is not something > >> > > regulars user would notice. > >> > > > >> > > System integrators and administrators might use tools that drop in > >> > > ifcfg files during automated installations (e.g. via kickstart or a > >> > > configration management tool). > >> > > They will need to update their tools -- convert the ifcfg files to > >> > > keyfiles or include the ifcfg sub-package. > >> > > > >> > > == Dependencies == > >> > > N/A > >> > > > >> > > == Contingency Plan == > >> > > * Contingency mechanism: If it turns out we can't drop support for > >> > > ifcfg files by default, we can either fold the ifcfg sub-package back > >> > > into the main NetworkManager package or make sure it is included in > >> > > new installations (via comps change). > >> > > * Contingency deadline: Any time. > >> > > * Blocks release? No. > >> > > > >> > > == Documentation == > >> > > We'll need to write the documentation for the migration tool. > >> > > Perhaps also something the sysadmins wondering why their ifcfg files > >> > > don't work anymore could find and refer to. > >> > > > >> > > TODO: Update this once it's done. > >> > > > >> > > == Release Notes == > >> > > We'll need to include a paragraph about this in the release notes. > >> > > > >> > > TODO: Update this with the actual release note text. > >> > > > >> > > >> > This will break cloud-init, since it doesn't know how to configure > >> > NetworkManager directly. It only knows how to configure netplan (which > >> > isn't packaged in Fedora currently), ifcfg-rh, and ifupdown configuration files. > >> > > >> > If you want to do this, you need to extend cloud-init to be able to > >> > configure NetworkManager properly. > >> > >> Or replace cloud-init with an equivalent that does. > > > >There are none. Ignition deliberately cannot configure the network, > >and as a CoreOS tool, it is incapable of configuring the system to the > >same level cloud-init can anyway. Older versions of Ignition could > >configure systemd-networkd, but I don't want to ship that either. > > > >Fedora Cloud will be forced to disable NetworkManager and switch back > >to legacy network-scripts if this Change goes through. I don't want to > >do that, because I *like* NetworkManager. I guess I could modify the > >NetworkManager config as part of creating the image to re-enable the > >ifcfg-rh plugin, but if it is getting disabled by default, it's not > >far away from getting dropped. > > Not completely familiar with cloud-init, but what is preventing cloud-init > from configuring NetworkManager vs the old ifcfg scripts? That feels like an > easy enough thing to do what with a combination of NetworkManager.conf and > perhaps some other files that NM would read. > There's just no configuration renderer code in cloud-init for NetworkManager. The ifcfg code is effectively maintained by the RH contributors to cloud-init, so I'm really surprised this Change was proposed without talking to them about a plan to fix that issue. I filed a bug about this issue a few months ago, even: https://bugzilla.redhat.com/show_bug.cgi?id=2014701 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
