Evolving prepare-image syntax

(This is from a email discussion from a while ago)

At the moment prepare-image takes:

  • --channel that will be applied to all snaps (this does not make a lot of sense)
  • --extra-snaps to specify extra snaps or local overrides to snaps defined as needed by the model

--extra-snaps is used both with prepare-image and ubuntu-image as:

... --extra-snaps my-local.snap   --extra-snaps pc-kernel.snap   --extra-snaps mysnap

We miss a way to control the installation options of each single snap like ā€œsnap installā€ allows, a strawman proposal is to

  • deprecate --extra-snaps but keeping it for now
  • deprecate --channel and/or making it mean the default channel if nothing else is specified

Introduce

  • --snap (that can be repeated as --extra-snaps can now)

working like --extra-snaps today but with the option of adding suffixes separated by ā€œ:ā€ based on the options that can be given to ā€œsnap installā€ (probably we start with a subset):

--snap mysnap

--snap mysnap:devmode

--snap mysnap:edge:devmode

--snap mysnap:devmode:channel=edge

and also

  • --assert <file-with-stream-of-asserts> (can be repeated)

to support adding extra assertions to the image (these initially would be checked and complemented by fetching assertions from the store as we do for the model assertion now, we can think of more modes later if needed).

2 Likes

I like the proposal to use --snap. Depending on the discussion in How to specific the kernel snap on core18 it will allow us to write: ubuntu-image --snap pc-kernel:channel=4.15/stable core-amd64-18.model.

Given that we have chosen to use <snap>=<track> in the model assertion, it is now more natural to just go and add support for --snap <snap>=<channel|risk> in prepare-image:

https://github.com/snapcore/snapd/pull/6469

About further flags, in actuality prepare-image already auto-detected the need for devmode, and now will do the same for classic (of course not for core images where that is an error), see https://github.com/snapcore/snapd/pull/6467

cc @sil2100

2 Likes

--snap support has landed and will be in 2.38.

I would be against deprecating --channel, since itā€™s not only used for the case of extra snaps but also for the general case of where should all the model-defined default snaps come from (core, snapd, gadgets etc.). Having --channel deprecated completely and having to state each of the snaps separately for a given model to get for instance an edge-based image build seems like a very unpleasant experience. So Iā€™d say --channel acting as a ā€˜default channelā€™ seems like the right way to go.

thatā€™s what is implemented ATM fwiw

Two new switches is being introduced with 2.60.

--revisions Specify a seeds.manifest file referencing the exact revisions/sequences of the snaps and validation-sets which should be used during image seeding.

--write-revisions Writes a manifest file containing references to the exact snap revisions and validation-sets used for the image. A path for the manifest is optional.

These two switches allow for creating reproducible images by specifiying exact revisions of the snaps that should be installed. With the write-revisions switch it will also produce a seed.manifest file that specifies which snaps the image was built