Yes per #4. The shift to drop NoCloud metadata templates from cloud image streams forces cloud-init to use the DatasourceLXD and consume data from `/dev/lxd/sock` instead of the rendered no-cloud seed files that get written to /var/lib/cloud/seed/nocloud-net/. Turns out the datasurfaced from `/dev/lxd/sock` was formatted using Printf instread of Print (and fixed in upstream LXD already) which only affects the `dev/lxd/sock` path.
There is a related upstream issue Simon filed https://github.com/lxc/lxd/issues/10951 which looks like it already has a backport commit from @tomparrott. If that commit gets released to LXD.4.0 stable branch easily then we can keep the cloud images in their current state. But, if a stable backport of the fix in LXD takes a while I suggest we have the cloud-images revert https://github.com/lxc/lxd/issues/10951
Yes per #4. The shift to drop NoCloud metadata templates from cloud image streams forces cloud-init to use the DatasourceLXD and consume data from `/dev/lxd/sock` instead of the rendered no-cloud seed files that get written to /var/lib/ cloud/seed/ nocloud- net/. Turns out the datasurfaced from `/dev/lxd/sock` was formatted using Printf instread of Print (and fixed in upstream LXD already) which only affects the `dev/lxd/sock` path.
There is a related upstream issue Simon filed /github. com/lxc/ lxd/issues/ 10951 which looks like it already has a backport commit from @tomparrott. If that commit gets released to LXD.4.0 stable branch easily then we can keep the cloud images in their current state. But, if a stable backport of the fix in LXD takes a while I suggest we have the cloud-images revert https:/ /github. com/lxc/ lxd/issues/ 10951
https:/