[14:55] <cjp256> esv: did you sort out that mount issue by chance?  the pastes are 404ing
[14:57] <esv> sort of, give me a moment to explain it further
[15:02] <esv> 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] <esv> or at least it will force the modules to be called more often than once per-instance 
[16:45] <meena> https://cathode.church/@meena/110729982907967506 an ouroboros of yaks 
[16:50] <esv> hey folks, is once-per-instance executed when the  iid changes or whenever the machine is started from de-allocated state?
[16:50] <minimal> esv: a iid change is a new instance
[16:53] <esv> that I already understood
[16:54] <esv> 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] <minimal> esv: so you know the answer to your question then
[16:54] <esv> according to me once-per-instance should not execute then but one of my colleagues says otherwise 
[16:55] <minimal> 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] <esv> I guess I need to redefine the question
[16:56] <esv> are once-per-instance stcripts only run when the iid changes
[16:58] <minimal> 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] <esv> thank you minimal, I would interpret the "no pre-existing iid" as a iid change. 
[16:59] <minimal> to be more precise, upon boot after a iid change (as cloud-init runs as part of booting process)
[17:03] <minimal> so the question is whether Azure provides a new iid or the same iid when a machine is restarted from deallocated state
[17:04] <esv> no, it does not provide a new iid unless you execute cloud-init clean b4 the reboot
[17:08] <minimal> 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] <cjp256> The instance id should not change between allocations on Azure.
[17:41] <blackboxsw> 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] <blackboxsw> 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] <blackboxsw> esv* rather
[17:43] <esv> blackboxsw, thnx
[17:44] <blackboxsw> yeah, think I'm just restating what minimal said, but with some extra context
[17:44] <blackboxsw> thx cjp256