On Wed, Jan 05, 2022 at 09:41:35AM -0600, David Duncan wrote:
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
For clarification.... I was aware that cloud-init existed, but was not
familiar with what all it did or how it worked internally.
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
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
