Peter Robinson <pbrobinson@xxxxxxxxx> writes: > 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. I am a little sceptical of what that will be. If you look at the gambit of cloud-init functionality, the replacement is not going to be ignition just yet. I am happy to say that the networking is basically comparable, but there are years of improvements in cloud-init that aren't yet handled as they are in cloud-init for users who wish to configure once and use in many situations (and other distributions). Cloud-init and other applications, such as the ec2-net-utils, are still using the scripting and techniques there. It would be ideal if this also included a path for updating at least cloud-init to work with the new scheme. Otherwise, I would see this as a change that forfeits a lot of complex configuration behavior for volume management (including ephemeral volumes), repository management, etc. If you limit the argument to simply the scope of the networking decision, then the cloud-init functionality is effectively covered by ignition, et. al., but the network configuration isn't even a tenth of what we would forfeit to make the change in the cloud environment. The effective gain for that would be a decreased boot time since the configuration would maintain fewer configuration possibilities. In another part of the thread, David Cantrell mentioned that he is not familiar with cloud-init. This is typical in our community. For those not directly involved with building cloud configurations, it had a negative growth period, especially for the RPM distributions, during the whole upstart period. It was basically ignored afterwards, but it continued to add significant boot time value to the cloud instance behaviors in both public cloud and private environments now that it is supported in virtools. Many have built their own replacements (like CoreOS, Google, and Azure), but none have acheived the cross compatibility and generic support that cloud-init has. In most of those cases it has mostly been replaced in an effort to decrease boot time and limit functionality to force the configuration time into the user space instead of prior to instance service checks or replace the slower python with a compiled language like go. In all of those cases, the implementation has been an base compatibility product and not a full implementation of the cloud-config options. I think that if you don't constrain the discussion to networking, you will see that the cloud-config options in cloud-init are too significant to replace just yet. - David _______________________________________________ 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
