The live server installer is soon going to allow the user to select snaps to install while the installation proceeds. Under the hood, this downloads the snaps and assertions using ‘snap download’ and updates the seed.yaml.
One thing that this misses is that one of the downloaded snaps might depend on another snap via the content interface.
I don’t think this is massively serious because (a) server-ish snaps probably don’t use the content interface as much as desktop-ish ones (b) by my understanding the needed snaps will be downloaded during seeding anyway.
But it’s still a gap that I’d like to close. As things stand today, it looks like the only way I can find out which interface a not-installed snap plugs is to fish the meta/snap.yaml out of it and parse it myself, which sounds ugly. The ideal thing for me would be for snapd’s /v2/find endpoint to include data about this (maybe it could list all interfaces that would be plugged by default?), which presumably means the store would need to extract and present this information too. So I won’t hold my breath for that, unless there are already plans in this direction?
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1767896 (“Live 18.04 with broken seed causes snapd high CPU usage”) is a bug in the same sort of general area, in that a solution to my problem would allow the machinery about snap seeding in images to solve this sort of problem in a general way.
as I discussed with @mwhudson it doesn’t make sense for code external to snapd to learn how to chase the recommended/required other snaps for a give snap (this set and relevant rules can change over time); we likely need to:
short term: expose the base of a snap over the snapd API
seeding code should learn to order things such that it installs first bases and then default-providers if present (would address the mentioned bug)
prepare-image needs to learn to fetch bases and default-providers for the installed snaps
prepare-image should grow a mode to deal with setting up the seed for a classic system
I think I understand what all that means and it makes sense. It is indeed true that what I am doing (and also livecd-rootfs) is about 30% of what snap prepare-image does (the stuff to do with handling --extra-snaps).
Two things the live-server needs above what you described is a mode to update a system that has already been seeded, currently prepare-image will shout at you if you try to do that, and the ability to specify the channel per snap.
Tangentially, if all this becomes a matter of handing off a list of snaps to an invocation to ‘snap prepare-image --update --extra-snaps snap1,snap2,snap3’, I’d also like to have some kind of more structured progress reporting! My current branch shows a message as each snap is being downloaded and allows retry/ignore of failed downloads, I’m not sure how that would work if the snap binary is doing it all…
Seeding code itself now order things to deal with bases first, about default-providers we detect when the two sides will be installed sequentially and given that auto-connection is symmetrical just let the later install be responsible for it. (2.35)
There is no fetching so far but just warning if these were not listed explicitly. (2.36)
Well I think this would be fine but I’d want some kind of progress reporting. As this is (I think?) a command that /usr/bin/snap executes directly vs being an API call that snapd executes, I presume I can’t follow progress over http?
I remember that, atm the issue tough is also that prepare-image doesn’t download bases or content-providers, it just warns that they are missing. There is some logic to that, is bad form to have implicit snaps in an image, but it’s not a behavior that fits your use case, so it would need to do that downloading optionally or be invoked multiple time in some dry-run mode while the driver downloads snaps until everything is fulfilled.
In the context of current work we are refactoring seed writing to have a first class Writer, the Writer API should more easily allow to have a dry-run mode, or write simply a separate tool with that sort of behavior:
