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

[Ben Cotton]

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(a)v3.sk&gt;

* Name: Ana Cabral
* Email: <acabral(a)redhat.com&gt;

* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller(a)redhat.com&gt;

== 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_...
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

[Neal Gompa]

On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)v3.sk&gt;
>
>  * Name: Ana Cabral
>  * Email: <acabral(a)redhat.com&gt;
>
>  * Name: [[User:Thaller| Thomas Haller]]
>  * Email: <thaller(a)redhat.com&gt;
>
>  == 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_...
>  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!

[Peter Robinson]

On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)v3.sk&gt;
>  >
>  > * Name: Ana Cabral
>  > * Email: <acabral(a)redhat.com&gt;
>  >
>  > * Name: [[User:Thaller| Thomas Haller]]
>  > * Email: <thaller(a)redhat.com&gt;
>  >
>  > == 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_...
>  > 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.

[Neal Gompa]

On Wed, Jan 5, 2022 at 9:11 AM Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)v3.sk&gt;
>  > >
>  > > * Name: Ana Cabral
>  > > * Email: <acabral(a)redhat.com&gt;
>  > >
>  > > * Name: [[User:Thaller| Thomas Haller]]
>  > > * Email: <thaller(a)redhat.com&gt;
>  > >
>  > > == 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_...
>  > > 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!

[Colin Walters]

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-conf...

>  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.

[Neal Gompa]

On Wed, Jan 5, 2022 at 9:42 AM Colin Walters <walters(a)verbum.org&gt; 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-conf...
>  
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.




-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jonathan Lebon]

On Wed, Jan 5, 2022 at 9:46 AM Neal Gompa <ngompa13(a)gmail.com&gt; 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-7...

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.

[Neal Gompa]

On Wed, Jan 5, 2022 at 10:33 AM Jonathan Lebon <jlebon(a)redhat.com&gt; wrote:
>  On Wed, Jan 5, 2022 at 9:46 AM Neal Gompa <ngompa13(a)gmail.com&gt; 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-7...
>
>  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.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[David Cantrell]

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(a)gmail.com&gt; wrote:
> >
> > On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> > >
> > > On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)v3.sk&gt;
> > > >
> > > > * Name: Ana Cabral
> > > > * Email: <acabral(a)redhat.com&gt;
> > > >
> > > > * Name: [[User:Thaller| Thomas Haller]]
> > > > * Email: <thaller(a)redhat.com&gt;
> > > >
> > > > == 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_...
> > > > 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.

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Neal Gompa]

On Wed, Jan 5, 2022 at 9:52 AM David Cantrell <dcantrell(a)redhat.com&gt; 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(a)gmail.com&gt; wrote:
>  >>
>  >> On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >> >
>  >> > On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton(a)redhat.com&gt;
> 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(a)v3.sk&gt;
>  >> > >
>  >> > > * Name: Ana Cabral
>  >> > > * Email: <acabral(a)redhat.com&gt;
>  >> > >
>  >> > > * Name: [[User:Thaller| Thomas Haller]]
>  >> > > * Email: <thaller(a)redhat.com&gt;
>  >> > >
>  >> > > == 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_...
>  >> > > 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



-- 
真実はいつも一つ！/ Always, there's only one truth!

[David Duncan]

Peter Robinson <pbrobinson(a)gmail.com&gt; writes:

>  On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
> >
> > On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)v3.sk&gt;
> > >
> > > * Name: Ana Cabral
> > > * Email: <acabral(a)redhat.com&gt;
> > >
> > > * Name: [[User:Thaller| Thomas Haller]]
> > > * Email: <thaller(a)redhat.com&gt;
> > >
> > > == 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_...
> > > 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

[Colin Walters]

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)

[David Cantrell]

On Wed, Jan 05, 2022 at 09:41:35AM -0600, David Duncan wrote:
> Peter Robinson <pbrobinson(a)gmail.com&gt; writes:
>
> > On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >>
> >> On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton <bcotton(a)redhat.com&gt; 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(a)v3.sk&gt;
> >> >
> >> > * Name: Ana Cabral
> >> > * Email: <acabral(a)redhat.com&gt;
> >> >
> >> > * Name: [[User:Thaller| Thomas Haller]]
> >> > * Email: <thaller(a)redhat.com&gt;
> >> >
> >> > == 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_...
> >> > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Sérgio Basto]

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(a)v3.sk&gt;
>  
>  * Name: Ana Cabral
>  * Email: <acabral(a)redhat.com&gt;
>  
>  * Name: [[User:Thaller| Thomas Haller]]
>  * Email: <thaller(a)redhat.com&gt;
>  
>  == 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_...
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to
>  devel-announce-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure 
-- 
Sérgio M. B.

[Neal Gompa]

On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto <sergio(a)serjux.com&gt; 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!

[Zbigniew Jędrzejewski-Szmek]

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(a)serjux.com&gt;
> 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

[Adam Williamson]

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(a)serjux.com&gt; 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/ta...
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/fi...
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openqa/worker/te...

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/fi...

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. :)
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Colin Walters]

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/a3834830db2ff66e436...

(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)

[Neal Gompa]

On Wed, Jan 5, 2022 at 9:48 AM Colin Walters <walters(a)verbum.org&gt; 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/a3834830db2ff66e436...
>
>  (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!

[Peter Boy]

>  Am 05.01.2022 um 15:05 schrieb Ben Cotton
> <bcotton(a)redhat.com&gt;:
>  
>  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.

[Lukas Zapletal]

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

[Lukas Zapletal]

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.