RFC/Brainstorm New model assertion for Core18

1

For the coming Ubuntu Core 18 we will need new model assertions. The current models are called:

  • pc-amd64
  • pc-i386
  • pi2
  • pi3
  • cm3
  • dragonboard

I would like to discuss options for the new name. Maybe:

  • ubuntu18-{amd64,i386,pi2,pi3,cm3,dragonboard}
  • ubuntu-core18-{amd64,i386,pi2,pi3,cm3,dragonboard}
  • core18-{amd64,i386,pi2,pi3,cm3,dragonboard}
  • series18-{amd64,i386,pi2,pi3,cm3,dragonboard}
  • 18-{amd64,i386,pi2,pi3,cm3,dragonboard}

Here is a strawman for the content (amd64):

{
    "type":"model",
    "authority-id": "canonical",
    "series": "16",
    "brand-id": "canonical",
    "model": "pc-amd64",
    "architecture": "amd64",
    "gadget": "pc",
    "timestamp": "2018-05-29T05:58:10+00:00"
    "base": "core18",
    "display-name": "Ubuntu Core 18 (amd64)",
    "required-snaps": ["snapd"],
    "kernel": "pc-kernel/18",
}

The parts below “timestamp” are new:

  • base: We use a base for booting now
  • display-name: This will be displayed by the bootloader (if it supports it)
  • required-snaps: Snapd is now split out of the core18 and is required for the system to work
  • kernel: The kernel has the same name as the “Ubuntu Core 16” kernel, so we either need a new kernel snap name for ubuntu-core-18 systems or we extend the syntax of the kernel line in the model assertion to allow supporting a track for the kernel (this is what the above proposes).
1 Like
2

If we use the track for the kernel it might make sense to use the actual kernel version as the track name: pc-kernel/4.15 for example.

As for the model assertions, is there a place where one can see the model assertion of a given device?

3

-1 (very confusing)

+1 (not sure about the exact spelling but something like this)

this is strange, unfortunate and annoying for people needing to make models. I think it would be best if we could make it implicit (as core was), probably based on base being set or something.

1 Like
4

I agree on the required-snaps and the need put snapd there. It’s better if this is implicit.

5

my vote goes to any name that still has “core” included (unless we rename the product) …

… so either of these two …

i would also include the architecture in the name of the different arm models (who knows, we might … in a state of insanity … build an arm64 pi3 image (because we like to run out of ram) or, to make sane use of the limited 1GB ram, build an armhf dragonboard image)

can this not be solved internally somehow ? it is after all a hard requirement. would be nice if this would not have to be manually configured in a configuration file but automatically by snap prepare-image itself.

maintaining it in a separate configuration just complexifies everything …