[14:55] esv: did you sort out that mount issue by chance? the pastes are 404ing [14:57] sort of, give me a moment to explain it further [15:02] I noticed disk_setup and mounts modules are under cloud_init_modules in /etc/cloud/cloud.cfg in my azure vms, I don't think that is the standard place [15:03] or at least it will force the modules to be called more often than once per-instance [16:45] https://cathode.church/@meena/110729982907967506 an ouroboros of yaks [16:50] hey folks, is once-per-instance executed when the iid changes or whenever the machine is started from de-allocated state? [16:50] esv: a iid change is a new instance [16:53] that I already understood [16:54] in Azure you can stop an instance, which the OS goes dormant and no charges are incurred then you kick it off again, you are almost guaranteed to get a new host hypervisor. [16:54] esv: so you know the answer to your question then [16:54] according to me once-per-instance should not execute then but one of my colleagues says otherwise [16:55] you mentioned "once-per-instance" and I indicated a change in iid is a new instance, therefore when the iid changes then the "once-per-instance" modules are executed [16:56] I guess I need to redefine the question [16:56] are once-per-instance stcripts only run when the iid changes [16:58] if you include the 1st boot when there is no pre-existing iid and so it is an idd change from "none" to the new iid, yes [16:59] thank you minimal, I would interpret the "no pre-existing iid" as a iid change. [16:59] to be more precise, upon boot after a iid change (as cloud-init runs as part of booting process) [17:03] so the question is whether Azure provides a new iid or the same iid when a machine is restarted from deallocated state [17:04] no, it does not provide a new iid unless you execute cloud-init clean b4 the reboot [17:08] as for disk_setup and mount modules, yes they are in cloud_init_modules section by default. Why would that cause them to be called more than once-per-instance? [17:40] The instance id should not change between allocations on Azure. [17:41] esv: sorry to jump in late on this thread. once-per-instance are run only when instance-id changes.... so, as you said "no pre-existing iid" -> "some uuid" also qualifies as that instance-id change.... and the only way you get to "no pre-existing iid" is a cloud image with cloud-init which was never launched, or a reboot that happens after a `cloud-init clean` because that removes the cached /var/lib/cloud/data/previous-instance-id [17:43] esn: and for general instance-id changes besides that, it's up to the cloud platform to determine when the meta-data/instance-id value changes. typically this would be over the migration of an instance to a new private network or significant changes in VM metadata. Some clouds change instance-id when new NICs are attached to an instance [17:43] esv* rather [17:43] blackboxsw, thnx [17:44] yeah, think I'm just restating what minimal said, but with some extra context [17:44] thx cjp256