Ubuntu-image utility does not take gated snaps into account

snapd
1

Using the gated/refresh-control of a set of snaps was the solution to be able to control and keep an consistent environment of external snaps in the Ubuntu Core/Snappy ecosystem.

This feature works on existing devices but not during the initial creation of the Ubuntu Core image.

I experience issues during creation of an initial Ubuntu Core/Snaps images were it used the wrong revision of the external snaps.
Instead the ubuntu-image tool uses the latest revision of these gated snaps.

Below shows an example using “ubuntu-image” utility with the gated/refresh-control feature.

###########################################################################
# Informational
$ ubuntu-image  --version
ubuntu-image 1.7+snap1
$ snap --version
snap    2.42
snapd   2.42
series  16
ubuntu  18.04
kernel  4.15.0-54-generic

# Apply gated/refresh-control
$ snapcraft validate <snap-name> core18=1220  pc-kernel=300 snapd=4990 ...

# Create Ubuntu Core Image.
$ ubuntu-image --hooks-directory setup-hooks -O img-export <name>.model

# Snaps within created core image
$ snap list
Name             Version        Rev   Tracking  Publisher      Notes
<snap-name>      1.0            798   stable    <Example>      -
core18           20191010       1223  stable    canonicalâś“     base
pc-kernel        4.4.0-165.193  304   stable    canonicalâś“     kernel
snapd            2.42           4992  stable    canonicalâś“     snapd

The gated snaps are not considered during creation of the Ubuntu Core image.

$ snapcraft gated <snap-name>
Name         Revision  Required    Approved
core18           1220  True        2019-10-01T10:00:00Z
snapd            4990  True        2019-10-01T10:00:00Z
pc-kernel         300  True        2019-10-01T10:00:00Z
###########################################################################

I’m aware that is possible fetch the gated snaps from snapstore API and then download the specific revision of snaps then using the “–snap” <local.snap> option in ubuntu-image which then allows me to get the expected result.
Trigger an refresh does revert to the gated snaps and schedules multiply restarts on the devices. NOTE: “core18” and “pc-kernel” snaps does not bundle the reboots during refresh which then results in 2 reboots but that’s outside the scope of this topic.

Not sure if this is the correct place/tag/project to report this but since the feature originate from snapcraft I assume this is within the interest of snapcraft/snapstore to have an toolchain that consider the gated snaps while creating the Ubuntu Core image.

2

I moved this to the #snapd category because I think your issue speaks to a larger design question about the refresh-control/gating features.

If I’m understanding the request here, you want to be able to build an image with snaps that also follows the restrictions enforced by refresh-control/gating. I don’t think that the refresh-control features were designed with this use-case in mind, but that being said I think that you might be able to work around this issue by trying a workaround:

  1. on your build machine, login to snapd with snap login using an account that has access to the brand store
  2. confirm that your build machine follows the same refresh-control / gating logic as what you expect on the device
  3. install ubuntu-image and try to build your image
  4. check that the image has the right snap revisions

I don’t know if this will work, since what ubuntu-image uses to assemble the image + snaps is snap prepare-image, and it’s not totally obvious to me that the prepare-image uses the same codepath that the refresh logic does to determine which revisions to use. It very well might not use the same codepath and may not work.

All that being said, I think that snap cohorts may be a better fit to this, but I don’t think ubuntu-image or snap prepare-image have been updated to use cohorts the same way that snap download and snap refresh have (see Managing cohorts). It’s also unclear to me how cohorts interact with refresh-control. :thinking:

@chipaca @pedronis can you take a look at this issue?

3

If we want ubuntu-image to support gating and stores and all that we’d need to make prepare-image talk to snapd to do the downloads, which is additional work on top of the currently-in-progress work to make snap download talk to snapd.

Cohorts seems like the wrong angle for this, given cohorts are shorter-lived than I expect models to be. But I could be wrong, and for completeness we might want to support them in the image context. This is orthogonal to going via snapd, though.

1 Like
4

The new version of ubuntu-image can support this feature.