This is automated, unattended deployments, which have no ability to "stop snapd.seeding, and run it again". That's not an acceptable solution. The unit is pulled into the initial transaction, failing or stopping it, will make the transaction fail, and will fail to complete the boot correctly and finish cloud-init on first boot, which needs to install snaps and have operation snapd which has completed seeding.
It sounds like we must remove seeded snaps from our LXD images, and not install any seeded snaps inside our container. And like only install the lxd stub deb. Cause it looks like seeding snaps is not supported inside classic lxd containers.
@snapd team
This is automated, unattended deployments, which have no ability to "stop snapd.seeding, and run it again". That's not an acceptable solution. The unit is pulled into the initial transaction, failing or stopping it, will make the transaction fail, and will fail to complete the boot correctly and finish cloud-init on first boot, which needs to install snaps and have operation snapd which has completed seeding.
It sounds like we must remove seeded snaps from our LXD images, and not install any seeded snaps inside our container. And like only install the lxd stub deb. Cause it looks like seeding snaps is not supported inside classic lxd containers.