Comment 7 for bug 2028888

On Sat, 19 Aug 2023 at 08:02, Łukasz Zemczak <email address hidden>
wrote:

> ...I think we need a better way of dealing with this.

Yes.

> Since what I did right now is make sure that the livefs and the 'FDE
> target' model have the same set of snaps. But apparently the set of snaps
> we install on the canary target are... limited?
>

Yeah I don't know quite why that's the way it is.

> This warrants figuring a better way of dealing with snaps.

No kidding.

> Adding new snaps to the model assertion is problematic, requires a signing
> round and updates to livecd-rootfs.

However, I don't think there is a way around it (irrelevant correction: it
requires either an update to livecd-rootfs or an upload to the store via
APIs only store admins have access to).

> This is suboptimal. I think we need to somehow make the livefs layer use
> the seeded snaps that we basically 'rip out' to the classic layer right now.
>

I don't think we can do this. When seeding a system with a uc20 style model
assertion, snapd will only seed

> I don't have the brain power to figure that out right now. Maybe
> mwhudson would have an idea for this already?

I have a few ideas for some things we should do but there's no way around
the signing round bit aiui.

Here's what we should do IMO:

1. make a decision about a source of truth for which snaps are part of a
default Ubuntu desktop install (probably the seed definition)
2. Write some tooling to update the list of snaps in the pre-signing model
JSON for the classic desktop model definition
 (Note that these snaps should have "presence: optional" so they can be
removed after install)
3. Same for the model assertion for the live installer environmnet
(4. Set up something in the spirit of component mismatches to yell at us
when these sets of snaps get out of sync)
5. Change the code in livecd-rootfs to make sure that all snaps in the
model are included in the seed (by default, snapd does not include
"presence: optional" snaps in the seed)