Seeding snaps that plug the content interface

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? (“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

cc @mvo

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.

When can I get it? :slight_smile:

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…

yes, that’s why it might be that in practice there will be a mode where prepare-image just constructs a list of snaps

will start at least looking into exposing bases of snaps over the API

I opened this for a start:

@mwhudson for a start exposing base over the snapd API will be in 2.34

An update on this (cc @mwhudson)

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)

Nothing happened on this front yet.

1 Like

A first iteration of this is being worked on

cc @sil2100 @mwhudson

I know @mwhudson was more interested in a sort of dry-run version of that tough.

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:

We now need cohort support as well.

Incremental seeding seems to work fine now.

I really like --classic mode.

It did ask for model name, I"m not sure what I should be specifying there for classic.

totally want to start using prepare-image in livecd-rootfs