=== vrubiolo1 is now known as vrubiolo
=== hjensas is now known as hjensas|afk
[17:16] <AnhVoMSFT> rharper - regarding your comment on this PR https://github.com/canonical/cloud-init/pull/880#discussion_r617733841 - those netdev mounts are in /etc/fstab, they should have their own .mounts unit and don't really rely on the mount -a command within init phase to get mounted
[17:16] <AnhVoMSFT> the mount -a is really only introduced recently (about a year) to deal with the case where cloud-init re-partition the ephemeral disk (upon discovering that new ephemeral disk was added when vm was started/stopped) and /etc/fstab was changed
[18:54] <rharper> AnhVoMSFT: are you suggesting they are in /etc/fstab prior to boot?
[18:55] <rharper> AnhVoMSFT: the mount -a is needed for any new mount that cloud-init adds due to the mounts: user-data;  on Azure you supply a default mounts data; but users are perfectly capable of providing their own as well (or instead of); in which case, systemd's fstab generator has not *yet* seen those entries in fstab that cloud-init writes in cc_mount.py;  hence the need for a mount -a
[19:13] <AnhVoMSFT>  rharper: the issue are mostly relevant for reboot. So yes, the mounts are in /etc/fstab prior to boot
[19:13] <AnhVoMSFT> the mount -a during reboot will try to mount those netdev mounts which will cause boot hang, since it's too early for netdev mounts
[19:32] <rharper> yes, I certainly see the -O no_netdev in the mount -a being useful, but I thought we checked fstab for entries added only ... we wouldn't call mount -a unless we have new mounts not in fstab ?
[19:34] <rharper> AnhVoMSFT: ^
[20:24] <tkonto> Hi all. not very familiar with cloud-init just following a hint from friend. I have a gold image of RHEL7 on which I need to change IP address, Hostname, and multipath.conf prior to cloning it 18 times. There is no cloud or Virtualization provider involved here. Just a machine and the disk image. Alter the image, deploy the new OS
[20:24] <tkonto> Could cloud-init be useful on that? For the IPaddr/Hostname for sure.. what about multipath.conf?
[20:32] <rharper> tkonto: hey, cloud-init doesn't have a config modules for multipath.conf built-in;  however, it has some primitives you could use; though it wouldn't help you get your rootfs together;
[20:33] <rharper> tkonto: but if you're templating an image that doesn't need to change at runtime, you might look at packer;  cloud-init is typically used at runtime to inject config during boot;
[20:36] <rharper> tkonto: if you still end up using cloud-init; and if you can do boot time modifications to multipath.conf (for not rootfs disks I would guess) then , you can use cloud-init's write_files to send a specific file, or runcmd if you have a shell program you want to use to modify the config.