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

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

 



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.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
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