[11:37] <otubo> Odd_Bloke: sorry for the delay on the response. Regarding your question on the bug https://bugs.launchpad.net/cloud-init/+bug/1894837 :
[11:38] <otubo> Odd_Bloke: Yes, RHEL uses NetworkManager on servers as well. Check the chapter 5. on the documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/pdf/configuring_and_managing_networking/Red_Hat_Enterprise_Linux-8-Configuring_and_managing_networking-en-US.pdf
[11:38] <otubo> ctrl+f "networkmanager" might be quicker :-D
[11:41] <otubo> Odd_Bloke: The patch I mention on the comment #8 of the bug (1894837) is maintained downstream only, because I think it makes sense to RHEL only. We could do some sort of check like if distro==RHEL then NM_CONTROLLED=True
[11:45] <otubo> Odd_Bloke: but I don't think it's really necessary since RHEL users normally use shipped package. Fedora also has this patched applied and CentOS too.
[14:05] <Odd_Bloke> otubo: Hmm, if this change is required for cloud-init to function as expected on RHEL and its related distros then it feels like something we should carry upstream somehow.
[14:11] <Odd_Bloke> otubo: Are there configurations of RHEL (and related distros, if you know) which don't use NM but do use sysconfig for networking?
[14:48] <AnhVoMSFT> @rick_h @rharper is there any other information that you need from Azure for this bug https://bugs.launchpad.net/cloud-init/+bug/1874544
[15:04] <meena> Odd_Bloke, otubo : that also the reason why CloudLinux doesn't work out of the box, i wonder?
[15:18] <rharper> AnhVoMSFT: I don't think so;
[15:43] <Odd_Bloke> meena: Nope, that's because CloudLinux claims to be CloudLinux in /etc/os-release and we don't have support for CloudLinux in cloud-init (yet).
[15:52] <meena> Odd_Bloke, is it really necessary to keep adding more distro classes, when all we need to know is which distro it's *like*?
[17:02] <Odd_Bloke> meena: How do we define what distro it's like?
[17:15] <meena> Odd_Bloke: os-release has an ID_LIKE field
[19:05] <Odd_Bloke> The semantics of that are very "best effort" ("It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces"); cloud-init is integrated too closely into systems to be relying on that.
[19:05] <Odd_Bloke> I'm not saying we couldn't use it as a fallback if we don't recognise a distro at all, but I don't think we can trust its values to be correct for cloud-init.
[19:06] <Odd_Bloke> Consider for example the EuroLinux PR: the submitter doesn't want to add "eurolinux" to a list because "centos" isn't in the list (although "rhel" _is_).  Do you think "centos" is first in ID_LIKE on EuroLinux, or is "rhel"?
[19:07] <Odd_Bloke> I don't know for sure, but I wouldn't be surprised if "rhel" were first, which would mean cloud-init would be doing the wrong thing on EuroLinux systems if we trusted ID_LIKE.
[20:53] <meena> Odd_Bloke: how different are rhel and centos? (allowed to be?)
[23:16] <beantaxi> Hello all ... I just spun up a new Ubuntu instance, and cloud-init is indeed 20.3! I did notice something -- it appears that the autocomplete for `cloud-init devel` has not been updated. It still only shows net-convert and schema. The new commands (make-mime and render) to appear to be there though. https://codeshare.io/a3V3pz
[23:16] <beantaxi> I don't know if this was a regression, or if the autocomplete was never updated, but I wanted to share.