| === vrubiolo1 is now known as vrubiolo | ||
| === hjensas is now known as hjensas|afk | ||
| 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 | 17:16 |
| rharper | AnhVoMSFT: are you suggesting they are in /etc/fstab prior to boot? | 18:54 |
| 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 | 18:55 |
| 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:13 |
| 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:32 |
| rharper | AnhVoMSFT: ^ | 19:34 |
| 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:24 |
| 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:32 |
| 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:33 |
| 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. | 20:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!