=== EugenMayer3 is now known as EugenMayer [17:28] falcojr: was there a changeset you have left to push for your schema branch per the last round of review comments? https://github.com/canonical/cloud-init/pull/1365#pullrequestreview-932378978 [17:28] Pull 1365 in canonical/cloud-init "schema: add json defs for modules scripts-timezone (SC-801)" [Open] [18:31] Woot and LXC support of per-instance re-config in cloud-init LXD datasource is working. Roadmap ✔ [18:31] it'll be officially in LXD 5.0 [18:32] then we can start working toward hotplug options there I hope. [18:38] @blackboxsw: Nice! [19:11] hey folks, I have a couple of machines in azure with multiple ip addresses assigned to them on the portal, the adapter is set to use dhcp but after a: cloud-init clean; loud-init init, operation, the machine loses all but one IP [19:12] any idea why/how to troubleshoot? [19:16] @esv one thing off the top of my head, is that generally if you run cloud-init clean, a reboot is probably preferred to run all of cloud-init's boot stages. As it is, you only re-ran `cloud-init init` and skipped over the preceding `cloud-init init --local` as well as the other stages [19:17] esv: see this answer I posted here https://stackoverflow.com/a/71152408/8479562. Given Azure datasource is detected during `cloud-init init --local` I think instead of `cloud-init init` (networking) stages the default behavior would be for cloud-init to use a default fallback network configuration (dhcp on eth0). I presume this is what's happening for you [19:19] hope that helps a bit. Otherwise you can probably also validate what cloud-init thinks it wrote for network config with `grep 'Applying network config' /var/log/cloud-init.log` [19:31] thank you.