Evolving prepare-image syntax

pedronis
upcoming

#1

(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

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.


#3

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:

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


#4

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


#5

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.


#6

that’s what is implemented ATM fwiw