[07:59] <Number8> Hi everyone, I'm investigating a problem with cloud-init version 22.1. When I use it to configure almalinux 9.1, cloud-init configure the network with the files /etc/sysconfig/network-script/ifcfg-*
[08:00] <Number8> I think cloud-init 22.1 is too old but I'm not sure
[08:11] <meena> Number8: yeah, Alma is pretty new, maybe upgrade to the latest cloud-init and see how that does for you
[11:46] <caribou> Hello, I've been using a custom built cloud-init from source to implement our DataSourceScaleway : cloud-init-23.1+70.g34637a49-1.el9.noarch
[11:46] <caribou> which works fine on rockylinux-9.
[11:46] <caribou> Since 23.2 came out, I rebuilt a new cloud-init-23.2-1.el9.noarch but now after installation I have no network.
[11:46] <caribou> The command `nmcli connection up filename /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection` fails with 
[11:46] <caribou> Connection activation failed: No suitable device found for this connection (device lo not available because device is strictly unmanaged).
[11:47] <caribou> While I investigate what is added b/w commit 34637a49 and the 23.2 tag I thought I'd ask here
[11:56] <caribou> I also noticed the following message at the console during reboot :
[11:56] <caribou> modules.py[WARNING]: Could not find module named cc_refresh_rmc_and_interface (searched ['cc_refresh_rmc_and_interface', 'cloudinit.config.cc_refresh_rm
[11:56] <caribou> c_and_interface'])
[13:33] <caribou> ok, I identified the change : 009dbf85a72a9077b2267d377b2ff46639fb3def - net/sysconfig: enable sysconfig renderer if network manager has ifcfg-rh plugin*
[13:35] <caribou> For some reason it triggers the creation of a bad /etc/sysconfig/network-scripts/ifcfg-eth0 on RockyLinux 9 only. For the others the file is not touched by cloud-init
[13:43] <minimal> caribou: 23.2 removed the refresh_rmc_and_interface module but you must be using an old /etc/cloud/cloud.cfg (or file in /etc/cloud/cloud.d/*) that still references this module
[13:44] <caribou> yeah, I noticed that while investigating. I'll clean up the conf file
[14:05] <minimal> caribou: I'm not familiar with networkmanager so can't help there but if you have cloud-init debugging enabled then cloud-init.log should show how it handled network config and rendered it to the appropriate format
[14:05] <caribou> thanks for the tip. I'll try to dig in further tomorrow
[15:03] <falcojr> caribou: that PR added better sysconfig detection. My guess is that Rocky has support for sysconfig but cloud-init wasn't detecting it and using the NetworkManager renderer instead. Now it is detecting sysconfig instead and doing something weird. If you have pre and post logs I could confirm. 
[15:05] <falcojr> the renders to use and their order is configurable in cloud.cfg.tmpl. If what I said is true, then we probably want to order NetworkManager detection before sysconfig on Rocky. 
[15:07] <caribou> falcojr: I'll try to provide the logs sometimes tomorrow
[15:24] <caribou> falcojr: here they are :
[15:24] <caribou> Good (i.e. before 23.2) :https://pastebin.mozilla.org/Ke8tyOAR
[15:24] <caribou> Bad : https://pastebin.mozilla.org/KAOuRoXo 
[15:25] <falcojr> yeah, so `2023-05-30 11:05:41,953 - __init__.py[DEBUG]: Selected renderer 'network-manager' from priority list: None` vs `2023-05-30 15:17:44,557 - __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list: None`
[15:26] <falcojr> changing the priority on Rocky would be a quick fix, but we should probably figure out why the sysconfig renderer isn't working correctly too
[15:38] <falcojr> huh... https://github.com/canonical/cloud-init/blob/main/config/cloud.cfg.tmpl/#L384
[15:42] <falcojr> if this file is used/rendered when building for Rocky, the ordering should automatically be correct. If a different cloud.cfg used or generated in the downstream build process, then it would need to be updated accordingly.
[15:47] <caribou> Right now, I'm generating packages directly from the GH source tools (i.e. make srpm)
[15:50] <minimal> caribou: perhaps you have a file in place to override the default renderers list (which is what I assume also happened regarding the refresh_rmc_and_interface module)
[15:50] <caribou> I'm on my way out but I'll check that tomorrow when I'm back. Thanks for helping out
=== djhankb4 is now known as djhankb
=== m_ueberall is now known as ueberall
[21:52] <meena> @fal
[21:52] <meena> @falcojr added your patch to my pull request
[22:28] <falcojr> Thanks! 
[23:14] <meena> @blackboxsw: remember how i said I plan to do some Kernel work? well, this thing here: https://github.com/lxc/lxd/pull/11761 triggers some unplanned kernel work.