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-configuration/#_via_ignition > 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
