[14:18] <AnhVoMSFT> rharper: nfs mounts in /etc/fstab will have their own .mounts generated by systemd generator. IMO, it should not be cloud-init responsibilities to bring them up. This has always been the case right? I don't think The "mount -a" command that was added to cc_mounts last year was meant to ensure nfs mounts are up before cloud-config
[19:22] <hggdh> rharper: AnhVoMSFT sent you a message a bit bofre you joined today. Here it is:
[19:23] <hggdh> 14:18 <AnhVoMSFT> rharper: nfs mounts in /etc/fstab will have their own .mounts generated by systemd generator. IMO, it should not be cloud-init responsibilities to bring them up. This has always been the case right? I don't think The "mount -a" command that was added to cc_mounts last year was meant to ensure nfs mounts are up before cloud-config
[19:30] <rharper> hggdh: thanks
[19:32] <rharper> AnhVoMSFT:    the fstab generator runs before cloud-init is started;  in your case where someone has offline added entries to fstab and boots up a new instance (or the same disk image); yes systemd will create .mount units for these existing mounts.   In a new instance where there are no nfs entries in /etc/fstab, but user-data includes mounts:  which are *NFS* based;  changing mount -a  in cc_mounts.py to mount -a -O no_netdev
[19:32] <rharper> will *skip* these firstboot nfs mounts;
[19:34] <rharper> so the suggested change regresses the case where on new-instance-firstboot and user-data with NFS mounts;  nothing will mount these entries added by cloud-init during cc_mount.py and the mount -a -O no_netdev will skip these newly added entries in fstab added by cloud-init;
=== hggdh is now known as hggdh-msft
=== hggdh-msft is now known as hggdh