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@v3.sk
* Name: Ana Cabral * Email: acabral@redhat.com
* Name: [[User:Thaller| Thomas Haller]] * Email: thaller@redhat.com
== 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_ifc... 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.
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton bcotton@redhat.com 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton bcotton@redhat.com 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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.
On Wed, Jan 5, 2022 at 9:11 AM Peter Robinson pbrobinson@gmail.com wrote:
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton bcotton@redhat.com 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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.
On Wed, Jan 5, 2022, at 9:22 AM, Neal Gompa wrote:
There are none. Ignition deliberately cannot configure the network,
This is not true. https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configu...
and as a CoreOS tool, it is incapable of configuring the system to the same level cloud-init can anyway.
Er, what? Please see the whole above doc. A big part of the idea of CoreOS is that our tooling is symmetric across bare metal and cloud - and in the bare metal world, *lots* of nontrivial networking problems come up. It's hard to understate the amount of time we've spent on this. IMO we have a quite cool model now - our live ISO *is* CoreOS too, but doesn't require networking by default to fetch Ignition. You can inject an Ignition config into the ISO, and then e.g. boot that ISO in systems like vSphere or attach via IPMI virtual media etc. That Ignition config can then contain an Ignition config for the *real* system with static IP address, etc.
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.
That's for the NM team to answer, but it certainly seems to me the simplest thing is for cloud-init systems to re-enable the ifcfg-rh backend for now.
On Wed, Jan 5, 2022 at 9:42 AM Colin Walters walters@verbum.org wrote:
On Wed, Jan 5, 2022, at 9:22 AM, Neal Gompa wrote:
There are none. Ignition deliberately cannot configure the network,
This is not true. https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configu...
That is not Ignition configuring the network, that is *you* knowing what an NM file looks like and dropping it in. With cloud-init, it knows how to access cloud provider data sources to get configuration information and translate it into machine network configuration automatically.
and as a CoreOS tool, it is incapable of configuring the system to the same level cloud-init can anyway.
Er, what? Please see the whole above doc. A big part of the idea of CoreOS is that our tooling is symmetric across bare metal and cloud - and in the bare metal world, *lots* of nontrivial networking problems come up. It's hard to understate the amount of time we've spent on this. IMO we have a quite cool model now - our live ISO *is* CoreOS too, but doesn't require networking by default to fetch Ignition. You can inject an Ignition config into the ISO, and then e.g. boot that ISO in systems like vSphere or attach via IPMI virtual media etc. That Ignition config can then contain an Ignition config for the *real* system with static IP address, etc.
Your model only works as long as *you* do the configuration. You solve *nothing* for networking as you defer to the user to provide the raw configuration. Your symmetry was done by eliminating the ability for Ignition to handle cloud system stuff to process and configure directly.
On Wed, Jan 5, 2022 at 9:46 AM Neal Gompa ngompa13@gmail.com wrote:
That is not Ignition configuring the network, that is *you* knowing what an NM file looks like and dropping it in. With cloud-init, it knows how to access cloud provider data sources to get configuration information and translate it into machine network configuration automatically.
For cloud-specific network configuration, we've been steering towards nm-cloud-setup. We do ship it in FCOS, but it's currently disabled by default pending more CI coverage and investigation:
https://github.com/coreos/fedora-coreos-tracker/issues/320#issuecomment-7914...
So in theory, we could drop support for ifcfg as this Change is proposing and add nm-cloud-setup. (And that'd take us closer to being able to move from cloud-init to Ignition, which would have lots of benefits too.)
I'm not sure how wide the gap between nm-cloud-setup and cloud-init is today though.
On Wed, Jan 5, 2022 at 10:33 AM Jonathan Lebon jlebon@redhat.com wrote:
On Wed, Jan 5, 2022 at 9:46 AM Neal Gompa ngompa13@gmail.com wrote:
That is not Ignition configuring the network, that is *you* knowing what an NM file looks like and dropping it in. With cloud-init, it knows how to access cloud provider data sources to get configuration information and translate it into machine network configuration automatically.
For cloud-specific network configuration, we've been steering towards nm-cloud-setup. We do ship it in FCOS, but it's currently disabled by default pending more CI coverage and investigation:
https://github.com/coreos/fedora-coreos-tracker/issues/320#issuecomment-7914...
So in theory, we could drop support for ifcfg as this Change is proposing and add nm-cloud-setup. (And that'd take us closer to being able to move from cloud-init to Ignition, which would have lots of benefits too.)
What benefits? From a usability, workflow, and configuration perspective, Ignition is a *huge* downgrade from cloud-init for most Fedora Cloud users. From my own experience with Fedora CoreOS in OpenStack and AWS, Ignition configuration is clunky and awkward compared to the nicely integrated support for cloud-init.
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@gmail.com wrote:
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton bcotton@redhat.com 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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.
On Wed, Jan 5, 2022 at 9:52 AM David Cantrell dcantrell@redhat.com 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@gmail.com wrote:
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton bcotton@redhat.com 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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
Peter Robinson pbrobinson@gmail.com writes:
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton bcotton@redhat.com 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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
I don't think we need to go too deep on this cloud-init vs Ignition thread; but you have a great message here and I just want to clarify some points, everything else you said here is fair/accurate/relevant from my PoV.
On Wed, Jan 5, 2022, at 10:41 AM, David Duncan wrote:
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 the case of Ignition, that's not quite accurate. I was not personally involved in the creation of Ignition, but this document lays it all out: https://coreos.github.io/ignition/rationale/
In particular, I don't think the boot speed or programming languages were ever a big part of the argument. To pick one thing from that list, the Ignition philosopy of running in the initramfs meaning you avoid whole large classes of race conditions of trying to re-configure the system in the middle of boot was a primary component. (OK this does lead into the language thing a bit I guess because no one sane wants Python in their initramfs, but it's really not about speed)
On Wed, Jan 05, 2022 at 09:41:35AM -0600, David Duncan wrote:
Peter Robinson pbrobinson@gmail.com writes:
On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton bcotton@redhat.com 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
a big BTW when /etc/init.d/network will be removed or migrate to systemd scripts ?
rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package = %{name}\n"
packge = initscripts-10.09-1.fc34.src.rpm sub-package = network-scripts
On Wed, 2022-01-05 at 09:05 -0500, Ben Cotton 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@v3.sk
Name: Ana Cabral
Email: acabral@redhat.com
Name: [[User:Thaller| Thomas Haller]]
Email: thaller@redhat.com
== 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_ifc... 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-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org 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-announce@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto sergio@serjux.com wrote:
a big BTW when /etc/init.d/network will be removed or migrate to systemd scripts ?
rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package = %{name}\n"
packge = initscripts-10.09-1.fc34.src.rpm sub-package = network-scripts
It's deprecated and expected to be retired eventually. I doubt a "port" would ever happen.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Jan 05, 2022 at 09:48:13AM -0500, Neal Gompa wrote:
On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto sergio@serjux.com wrote:
a big BTW when /etc/init.d/network will be removed or migrate to systemd scripts ?
rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package = %{name}\n"
packge = initscripts-10.09-1.fc34.src.rpm sub-package = network-scripts
It's deprecated and expected to be retired eventually. I doubt a "port" would ever happen.
Yes, nobody wants to touch those scripts with a ten foot pole, so they are on life support. NetworkManager and systemd-networkd are the replacements.
Zbyszek
On Wed, 2022-01-05 at 15:58 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 05, 2022 at 09:48:13AM -0500, Neal Gompa wrote:
On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto sergio@serjux.com wrote:
a big BTW when /etc/init.d/network will be removed or migrate to systemd scripts ?
rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package = %{name}\n"
packge = initscripts-10.09-1.fc34.src.rpm sub-package = network-scripts
It's deprecated and expected to be retired eventually. I doubt a "port" would ever happen.
Yes, nobody wants to touch those scripts with a ten foot pole, so they are on life support. NetworkManager and systemd-networkd are the replacements.
Has anyone given openvswitch an equivalent level of integration with NetworkManager as it has with init.d/network yet? I'm still using that in production for the Fedora openQA servers:
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/tasks... https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/files... https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/templ...
In particular, last I checked, there was no good way to replace the ifup-pre mechanism from init.d/network which I use to ensure the tap devices are created when we bring up the tap interfaces:
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/files...
I don't know if anyone else even knows that things exists (I'd never heard of it before I found it) but it sure is useful. :)
On Wed, Jan 5, 2022, at 9:05 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
== Summary == Do not not include NetworkManager support for legacy network configuration files by in new installations.
It'd be nice to note this Change is actually just doing for other editions what Fedora CoreOS has been doing since it was created. xref https://github.com/coreos/fedora-coreos-tracker/issues/24 and https://github.com/coreos/fedora-coreos-config/commit/a3834830db2ff66e43690a...
(Which would be, what the 3rd change for which we're just doing elsewhere what FCOS is doing already now? The rpmdb move, the sulogin one, and now this)
On Wed, Jan 5, 2022 at 9:48 AM Colin Walters walters@verbum.org wrote:
On Wed, Jan 5, 2022, at 9:05 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
== Summary == Do not not include NetworkManager support for legacy network configuration files by in new installations.
It'd be nice to note this Change is actually just doing for other editions what Fedora CoreOS has been doing since it was created. xref https://github.com/coreos/fedora-coreos-tracker/issues/24 and https://github.com/coreos/fedora-coreos-config/commit/a3834830db2ff66e43690a...
(Which would be, what the 3rd change for which we're just doing elsewhere what FCOS is doing already now? The rpmdb move, the sulogin one, and now this)
I think that shows that you're not doing this properly. None of those changes in FCOS were done as Changes. Nobody knew they were happening until *other* people started digging and proposing them. Nobody had a chance to judge them on their merits because you just *did* them and told nobody.
-- 真実はいつも一つ！/ Always, there's only one truth!
Am 05.01.2022 um 15:05 schrieb Ben Cotton bcotton@redhat.com:
https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
== Summary == Do not not include NetworkManager support for legacy network configuration files by in new installations.
…… == Scope ==
- Proposal owners: Split the ifcfg plugin into a subpackage package.
Make sure the ifcfg plugin stays on upgrades. Provide a migration tool.
... == 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.
A big ++ for that. It is overdue.
However, as members of the Server WG, I wonder how many administration tools, scripts and Ansible playbooks will need to be rewritten. We would need to have a test case as soon as possible and communicate that very actively in the sysadmin community. Otherwise, the surprise could be quite big.
The migration tool comes a bit short in the proposal. I consider it an indispensable prerequisite for this change. From my own unfortunate experience - I have had to make this change manually on our servers without a migration tool and without dedicated documentation - how tedious and time-consuming such an action is. And while I can't help with a migration tool, I can offer help for documentation, just in case there's a shortage of hands.
And may be, we should be prepared to postpone the change to F37 but provide the migration tool and doc with F36.
Hello,
I represent one of system integrators (Foreman configuration and provisioning management open source project). Thanks for the info.
I would like to ask for taking into consideration shipping some kind of syntax validation tool that could be executed to validate syntax of the new-style configuration. It would be important to have it implemented in a way that it does not require running NetworkManager, so users could actually use it even within kickstart %post section. We are not only interested in pure syntax check, but also semantic validation - depending on NetworkManager version, many of values are not considered valid and NetworkManager fails to bring connection up.
If such tool would have support for multiple versions of NetworkManager, like ksvalidator do, that would be the best possible user experience. One could easily check if a configuration is valid for particular NM version (thus Fedora or RHEL version). In addition, if such a tool was distributed as a subpackage, we could totally integrate this into our CI suite to regularly test our provisioning templates responsible for generating NetworkManager configurations. A precedent is grub2 which has a solid validator which we run in our CI to catch issues and bugs beforehand.
Thanks and cheers!
-- lzap
For the record, I also created an issue for NetworkManager project.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/895
I think this would be a huge help for many of us migrating to the new syntax - there are endless combinations of configurations and we need to support many of them.
-
Adam Williamson -
Ben Cotton -
Colin Walters -
David Cantrell -
David Duncan -
Jonathan Lebon -
Lukas Zapletal -
Neal Gompa -
Peter Boy -
Peter Robinson -
Sérgio Basto -
Zbigniew Jędrzejewski-Szmek