| 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 | 14:18 |
|---|---|---|
| hggdh | rharper: AnhVoMSFT sent you a message a bit bofre you joined today. Here it is: | 19:22 |
| 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:23 |
| rharper | hggdh: thanks | 19:30 |
| 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:32 |
| 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; | 19:34 |
| === hggdh is now known as hggdh-msft | ||
| === hggdh-msft is now known as hggdh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!