[17:28] <blackboxsw> 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
[18:31] <blackboxsw> Woot and LXC support of per-instance re-config in cloud-init LXD datasource is working. Roadmap ✔
[18:31] <blackboxsw> it'll be officially in LXD 5.0
[18:32] <blackboxsw> then we can start working toward hotplug options there I hope.
[18:38] <holmanb> @blackboxsw: Nice!
[19:11] <esv> 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] <esv> any idea why/how to troubleshoot? 
[19:16] <blackboxsw> @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] <blackboxsw> 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] <blackboxsw> 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] <esv> thank you.