Pre-seeded snaps are not necessarily available for use in cloud-init user-data

[Dan Watkins]

With some cloud software being moved to snaps, cloud-init needs to ensure that snaps have been preseeded before user scripts are run, as those user scripts may rely on the software within the snap being available for use.

[Dan Watkins (oddbloke)]

Ideally, we would be able to configure the images to specify whether or not they should block on preseeded snaps. We have some cases where command-line utilities are installed (and so we should block) but others where only a daemon is started (where there is limited utility in blocking).

[Scott Moser (smoser)]

The snap module, which processes 'snap' configuration [1] currently runs
just about as early as it can run. The snapd daemon is not available until
cloud_config_modules time frame [2], so use of 'snap' or any provided
commands is not possible before that.

This means that bootcmd cannot use snap provided commands, but runcmd
or user-scripts ('#!/bin/sh') can.

I'm marking this fix-released, if you disagree, please justify and re-open.

[1] http://cloudinit.readthedocs.io/en/latest/topics/modules.html#snap
[2] http://cloudinit.readthedocs.io/en/latest/topics/boot.html

[Dan Watkins (oddbloke)]

There isn't currently a systemd target that indicates that snapd has completed its preseeding, so cloud-init can't be ensuring that they are available like that. Does cloud-init do something specific to confirm that pre-seeding has been completed before the user script point?

(Note that preseeded snaps are those that are in place on the filesystem during image build, which snapd detects and installs on boot; this isn't achieved through cloud-init at all.)

[Dan Watkins (oddbloke)]

As we have preseeded snaps in bionic, we'll want this SRU'd there (at least).

[Scott Moser (smoser)]

An upstream commit landed for this bug.

To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=d5374bba

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-init - 18.2-59-gcd1de5f4-0ubuntu1

---------------
cloud-init (18.2-59-gcd1de5f4-0ubuntu1) cosmic; urgency=medium

  * New upstream snapshot.
    - openstack: Allow discovery in init-local using dhclient in a sandbox.
      (LP: #1749717)
    - tests: Avoid using https in httpretty, improve HttPretty test case.
      (LP: #1771659)
    - yaml_load/schema: Add invalid line and column nums to error message
    - Azure: Ignore NTFS mount errors when checking ephemeral drive
      [Paul Meyer]
    - packages/brpm: Get proper dependencies for cmdline distro.
    - packages: Make rpm spec files patch in package version like in debs.
    - tools/run-container: replace tools/run-centos with more generic.
    - Update version.version_string to contain packaged version. (LP: #1770712)
    - cc_mounts: Do not add devices to fstab that are already present.
      [Lars Kellogg-Stedman]
    - ds-identify: ensure that we have certain tokens in PATH. (LP: #1771382)
    - tests: enable Ubuntu Cosmic in integration tests [Joshua Powers]
    - read_file_or_url: move to url_helper, fix bug in its FileResponse.
    - cloud_tests: help pylint
    - flake8: fix flake8 errors in previous commit.
    - typos: Fix spelling mistakes in cc_mounts.py log messages [Stephen Ford]
    - tests: restructure SSH and initial connections [Joshua Powers]
    - ds-identify: recognize container-other as a container, test SmartOS.
    - cloud-config.service: run After snap.seeded.service. (LP: #1767131)

 -- Chad Smith <email address hidden> Wed, 23 May 2018 16:16:53 -0600

[Scott Moser (smoser)]

This bug is believed to be fixed in cloud-init in version 18.3. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3166