=== jchittum_ is now known as jchittum
[13:42] <AnhVoMSFT> rharper if you deploy VM, then add NFS mounts to /etc/fstab, then deallocate/start the VM again, mount -a will get executed
[15:48] <rharper> AnhVoMSFT: I guess the core issue is still that when cc_mounts runs networking *is* up; but on some OSes, the rpc daemon is not.   In the case of a firstboot instance which adds an nfs mount, the mount -a -O no_netdev will fail to mount the requested mount; and since it wasn't already in fstab, systemd-fstab-generator won't create a mount unit for it.   And clearly on your scenario the nfs mounts are present and systemd will
[15:48] <rharper> mount them.   However, if the rpcd issue were solved then mount -a would be perfectly fine thing to run exactly when it does.
[16:29] <Odd_Bloke> falcojr: I've completed validation on https://bugs.launchpad.net/cloud-init/+bug/1922739 (and performed my share of the regression testing); where are you at?
[16:29] <ubot5> Ubuntu bug 1922739 in cloud-init (Ubuntu Hirsute) "AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'" [Undecided,Confirmed]
[16:29] <falcojr> Odd_Bloke: close...got a few failures that look unrelated, but re-running a few of them just to be sure
[16:35] <Odd_Bloke> falcojr: OK, cool, once you're satisfied with your bug and regression testing (and have updated the tags on the bug), I think we're ready to ping an SRU person for release.
[17:13] <falcojr> Odd_Bloke: Done!  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1899299
[17:13] <ubot5> Ubuntu bug 1899299 in cloud-init (Ubuntu Hirsute) "do-release-upgrade from Trusty to Xenial breaks cloud-init init-local on reboot" [Undecided,Fix committed]
=== bswinnerton0 is now known as bswinnerton
[18:16] <falcojr> I pinged in #ubuntu-release
[20:12] <aswinr> Hi. Looking to get this reviewed and checked in for the upcoming SRU https://github.com/canonical/cloud-init/pull/878
[20:29] <falcojr> aswinr: Thanks and noted. We'll try to get to it in the next couple days
[20:29] <AnhVoMSFT> rharper: from rpcd perspective networking is not up because network-online.target has not been reached yet. Obviously there are distros dependent targets like systemd-networkd-wait-online that describes the point of "network is up, but just before network-online.target", but there's no guarantee there is such a target on every distro
[21:35] <rharper> AnhVoMSFT: sure; even so networking *is* up; and if we skip nfs mounts with -O no_netdev ; there's nothing that will bring up nfs mounts on firstboot.
[21:36] <rharper> the only other thought I had was to create a cloud-config.service.conf.d dropin which could use an ExecStartPre=   script which could grep for _netdev in /etc/fstab, and if so, mount -a -O _netdev (bring up any nfs mounts if grep finds some)
[21:37] <rharper> This would ensure nfs mounts are up prior to cloud-config.service running;