Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



-- 
真実はいつも一つ!/ 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux