[02:33] <smoser> tryfan, Odd_Bloke  fwiw, centos/rhel8 is restarting network manager in cloud-init-final.service
[02:34] <smoser> https://bugzilla.redhat.com/show_bug.cgi?id=1897616
[02:34] <ubot5> bugzilla.redhat.com bug 1897616 in cloud-init "[rhel-7]cloud-final.service fails if NetworkManager not installed." [Medium,New]
[10:42] <otubo> Odd_Bloke: tryfan oh the problems of timezones, but the time you were discussing I was already sleeping. But thanks to the proxy I can check it now :-D
[10:52] <otubo> Odd_Bloke: tryfan so, the NM restart by the end of cloud-init start is intentional. This is the patch that introduced it: https://git.centos.org/rpms/cloud-init/blob/5b08af153d005e60cd7619a00090b90357da7cfe/f/SOURCES/ci-Remove-race-condition-between-cloud-init-and-Network.patch
[10:53] <otubo> tryfan: this is an old bug that I'm trying to find time to work on, but basically there's a tiny race between cloud-init and NM. cloud-init should write dns=none to /etc/NetworkManager/conf.d/99-cloud-init.conf, but NM start a little bit BEFORE cloud-init can actually write it.
[10:55] <otubo> tryfan: When it happens, NM doesn't know it's supposed to ignore dns configuration. Upon shutdown NM will erase resolv.conf, on the next boot NM will read dns=none and nobody (NM or cloud-init) will end up configuring it.
[10:57] <otubo> tryfan: that's why I introduced this reload (another patch replaces try-restart by try-reload-or-restart). In this case cloud-init will write dns=none, NM will read this configuration becase we're reloading it and resolv.conf will remain untouched across reboots.
[11:01] <otubo> tryfan: per your problem description I didn't quiet understood what point in time you try to use the network and it doesn't work and when it starts to work normally. I'm happy to help, but if you believe this is a big bug, you can file a Bugzilla and assign it to me.
[11:02] <otubo> Odd_Bloke: also, can you take a look at my PR whenever you have time? https://github.com/canonical/cloud-init/pull/685
[12:21] <otubo> smoser: I was looking at your LVM support on growpart and I was wondering how do I get a partition number info from a device mapper (/dev/dm-1) I just can't find it.
[12:22] <otubo> smoser: we got this on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1810878
[12:22] <ubot5> bugzilla.redhat.com bug 1810878 in cloud-utils-growpart "[RHEL-8]growpart fails to resize a root partition on LVM" [Medium,New]
[12:23] <otubo> smoser: cloudinit/config/cc_growpart.py on the function device_part_info()  tries to get "partition" from sysfs from /dev/dm-1 and fails.
[14:29] <Odd_Bloke> otubo: Ack, thanks for the detailed explanation!  I can take a look at that PR today, yeah. :)
[14:31] <otubo> Odd_Bloke: thanks! :)
[16:13] <tryfan> otubo: Thanks for the clarification on that stuff. The longer version is that I'm using a product called Morpheus to provision the VMs. The general recommendation for images has been to disable NetworkManager and I've been worried that it's going to bite users the longer Morpheus doesn't play nice with NM.
[16:14] <tryfan> otubo: The issue I was having was because Morpheus was supplying search domain config, but the int itself was configured for DHCP, so cloud-init modifies resolv.conf with the info it's given, and the nameservers are wiped.  On NM restart, nameservers are restored but search domains are lost
[16:15] <tryfan> I'm honestly still trying to figure out the best way to deal with this
[16:23] <tryfan> For instance, the resolv_conf module doc specifies setting PEERDNS=no for DHCP enabled NICs, but provides no guidance on how to set that using cloud-init
[17:29] <meena> what the heck is dhcp6
[17:45] <Odd_Bloke> meena: DHCP for IPv6: https://en.wikipedia.org/wiki/DHCPv6
[18:10] <meena> Odd_Bloke, i don't think we support that on FreeBSD
=== wCPO9 is now known as wCPO