Development sprint March 5th, 2018


We’re doing a development-focused sprint in March 2018 to discuss features in progress and the work ahead.


Budapest, Hungary




Cross-team discussions

:white_check_mark: Overview of unsupported image hacks that are in use :white_check_mark: Snapcraft error handling :white_check_mark: Snapcraft pack via snapd :white_check_mark: Allow latest track to be an alias :white_check_mark: Default track concept :white_check_mark: Moving core18 build to foundations :white_check_mark: API compatibility in smart local proxies :white_medium_square: Update of kernel on Raspberry Pi

Work in progress

:white_check_mark: Application auto-start :white_check_mark: Command not found integration :white_check_mark: Testing in GCE :white_check_mark: Timer services :white_check_mark: Interface hooks :white_check_mark: Refresh deferring commands :white_check_mark: Gated xdg-open for files :white_check_mark: Repairs progress :white_check_mark: Configuration validation for core :white_check_mark: The “system” nickname :white_check_mark: Upcoming releases :white_check_mark: Entitlements / Powers :white_check_mark: Epochs :white_check_mark: Layouts + per snap snap-update-ns profiles :white_check_mark: User mounts + portals :white_check_mark: Remaining work on core18 :white_check_mark: Ubuntu Core 18 :white_check_mark: Service survival across refreshes :white_check_mark: Software watchdog support :white_check_mark: Snapshots :white_check_mark: Ubuntu Core 18 upgrade story :white_medium_square: Documentation :white_medium_square: Command snap connections :white_medium_square: APT integration :white_medium_square: Queuing of snapctl service commands

Work upcoming

:white_check_mark: Parallel snap installs :white_check_mark: Hotplug :white_medium_square: Auto-connect from the gadget :white_medium_square: Holding refreshes while apps are running :white_medium_square: Seccomp non-killing :white_medium_square: Gadget snap updates :white_medium_square: Configuration schemas :white_medium_square: Health checks


Application auto-start

  • Needs to go back to doing things the simple way
  • userd --autostart starts on session startup via desktop file
  • Matching via autostart field in the application stanza
  • Discard argv[0] from Exec line, pass args to usual app command
  • On second phase, we can use something else to exec the actual desktop file after validation and replacement of Exec line
  • To be released this week (no pressure)

Command not found integration

  • All client side bits are in place
  • SQLite database for storage
  • Server side extractor is rewritten and ready
  • Needs to be prepared for deployment, under discussion
  • Launchpad must be changed to include commands files in signed Release file
  • Snap store needs to send version information
  • Style to be tuned

Current proposals for style:

Exact matches, mixed formats
Command 'foo' not found, but can be installed as:

  foorer (1.2, snap)
  foomer (1.0, snap)
  foozer (1.1, deb)

See 'snap info <snap name>' for additional versions.
Exact matches, only snaps available
Command 'foo' not found, but can be installed as:

  foozer (1.1, snap)
  foomer (1.0, snap)

See 'snap info <snap name>' for additional versions.
Exact matches, only debs available
Command 'foo' not found, but can be installed as:

  foozer (1.1, deb)
  foomer (1.0, deb)

Try: sudo apt install <deb name>
Fuzzy matches, mixed formats
Command 'foo' not found, did you mean:

  command 'foor' from snap foorer (1.2)
  command 'foor' from snap foorer (1.2)
  command 'foom' from deb foomer (1.0)
  command 'fooz' from deb foozer (1.1)
  command 'fo' from deb foozer-somewhat-long (1.1)

See 'snap info <snap name>' for additional versions.
Fuzzy matches, only snaps available
Command 'foo' not found, did you mean:

  command 'foor' from snap foorer (1.2)
  command 'foor' from snap foorer (1.2)

See 'snap info <snap name>' for additional versions.
Fuzzy matches, only debs available
Command 'foo' not found, did you mean:

  command 'foom' from deb foomer (1.0)
  command 'fooz' from deb foozer (1.1)
  command 'fo' from deb foozer-somewhat-long (1.1)

Try: sudo apt install <deb name>

Overview of unsupported image hacks

  • There are images using arbitrary hacks in the write partition phase
  • Consider whether eth0 is correct as default for netplan configuration
  • Netplan configuration needs to be customizable for unattended installs
  • Some images chown /system-data/ recursively, which is a really bad practice
  • Most important thing to solve is social issue: open channel is needed for conversations, as no technical solution will work without a chance to replace hacks by supported methods

Snapcraft error handling

  • Snapcraft will learn to better handle errors in third-party code
  • Snapcraft will be able to send unknown errors to sentry, after interactive request
  • Traceback will be shown while offering to report error
  • Before asking to report errors, Snapcraft needs to get better at handling third-party errors

Snapcraft pack via snapd

  • Add snap pack --check-skeleton doing validation before pack
  • Do pack in snapcraft via snap pack command
  • snapcraft-snap-tool built with snapd, ships /usr/lib/snapd/snap
  • snapcraft looks for /usr/bin/snap first, then /usr/lib/snapd/snap
  • snapcraft deb depends on (snapcraft-snap-tool || snapd)
  • snapcraft-snap-tool package must be preferred on apt install, so people that don’t have snapd won’t pull it and potentially break their environment (e.g. docker, etc); but /usr/bin/snap must be preferred by snapcraft, so that an updated snapd is used when possible
1 Like

Testing in GCE

  • Spread google backend is ready
  • Pagination bug when listing old images, to be fixed this week
  • Developers have credentials
  • ubuntu-16.04-64 already using it in default snapd tests
  • More images coming soon
  • Login with: gcloud auth application-default login
  • Copy json credentials out of .config/gcloud when using confined spread

Timer services

  • Syntax is the same as refresh syntax (not by coincidence :-))
  • Generate .timer and .service files for systemd
  • snap run --timer only runs command if the window is right
  • Sharp schedules (10:00) allows running within the minute
  • It’s all merged, will be out with snapd 2.33.
1 Like

Allow latest track to be an alias

  • We should add support for a track to be an alias to a different track
  • Track aliases would be transparent to the client
  • Today publishers need to maintain the latest track and the latest major track manually, which is error prone
  • If a track is necessary for a previous major version (say, 1.0), there are good chances that there’s value in having the next major version (say, 2.0) in a track as well, so people can choose to stay in 2.0 even if 3.0 is released

Default track concept

  • Today the default track is the latest, always
  • That’s not very meaningful, as people can push whatever they want on latest
  • Some applications behave poorly when the client migrates from one major to the next
  • Epochs will help that situation, but epochs in general are about migrating the application itself. In some cases, the external users of the application (say, source code for a compiler) will stop working when the application itself is upgraded, even if the upgrade works correctly
  • The concept of a default track would sort that out: if snapd requests stable, unadorned with a track, the server might report back to snapd what the default track is, and that would be set as the current track, with everything else behaving the same from then on

Interface hooks

  • Pretty much ready. Three final PRs need reviews:
    1. Changes for: connect command, auto-connect task, refresh command
    2. Changes for: disconnect hooks, disconnect command, remove command
    3. PolicyCheck changes for Attrer interface
  • Needs test snaps exercising the functionality
  • Tests for auto-connect need a signed snap
  • Plug/Slot types need to be dropped
  • Needs documentation

Refresh deferring command

  • Initial driver for the feature is holding refreshes right after seeding in some cases, but also a generally requested feature
  • snap refresh --hold=2h
  • Effective hold time is the maximum absolute time between current hold and requested hold
  • It does not schedule a refresh after the requested time, but instead prevents the refresh from happening within that window
  • Disabling the hold window is possible via --hold=none
  • Hold time is stored in refresh.hold core configuration setting (public)
  • Hold can change many times before the actual window without affecting it
  • At the refresh attempt, if inside a hold window, skip it as long as it doesn’t go beyond the maximum number of days (60 days right now)
  • Must warn if requested hold cannot be respected due to maximum period
  • In the future, per snap holds will be possible, but probably done via direct question to the snap (hook) instead of via persistent setting
  • First version of the --hold implementation will be optimistic and trust that nobody changed the configuration setting concurrently
  • On a follow up we’ll support configuration “nonces” (or version) that will allow optimistic locking of the configuration: “proceed as long as the config hasn’t changed since I looked”
  • The command work is pending, and recomputing next when inside the hold is also pending, but the underlying implementation is already up for review

Gated xdg-open

  • Provides a way for snaps to open files in the snap filesystem
  • The snap runs xdg-open file://...
  • Request is transferred to the outside world via userd
  • A file descriptor is sent along with the request, and userd checks that the external path refers to the same file
  • A pop-up is opened to let the user decide to open the file or not
  • There’s a 5 minutes timeout to answer the question, after which the request is rejected by default
  • In the future there will be a way to make the choice sticky under some conditions
  • At the moment the popped up window no parent, so shows up in the middle of the screen. In the future we should be able to do better.
  • The implementation of xdg-open uses glib right now. That creates a dependency between snapd (the overall snap) and glib, which is a problem in a multi-base situation. We’ll port it to being a subcommand of snapctl this week.
  • xdg-open becomes a shell script running snapctl user-open file://...

Repairs progress

  • They work for a while now.
  • We have done a staging test, but not a production test yet.
  • Production test to be done in the next two weeks.
  • Future work: early boot runs, auto-import support, brand-signed repairs.

Configuration validation for core

  • Schemas are coming, but will take a little while
  • It’s cheap to just check on configuration changes that the options set are actually supported
  • Apply a patch so that unsupported options already in the configuration are first cleaned up
  • The patch is okay in this case because it does not break backwards compatibility; in fact, it makes it more compatible.
  • This might break people that have been abusing the core configuration for unsupported settings; that’s indeed unsupported and will break.

The “system” nickname

  • Rationale:
    • Gadget configuration defaults are based on snapd IDs
    • The snap IDs are different between staging and production stores, signed by different root keys
    • That makes it hard to write tests for some cases, since the gadget snap needs to refer to both the staging and production core snaps
    • Also, this is the most configured snap by far, so it’s convenient to have a nice short name for it
    • Also, it’s just weird to configure the “core” snap for what is in fact a system setting
    • Interface connections have a similar issue, with core:home being obtuse.
    • These are shorthanded as :home today, but they are still exposed under the core snap.
    • The core snap is becoming a base rather than a singleton, which will confuse things further.
  • For all of those reasons, we’re introducing a “system” label, that can be used in a few places:
    • Configuration options (gadget defaults, snap set/get, etc)
    • Interface connections
  • The “system” snap was registered to ensure it’s not used for other purposes.
  • Future snapd’s must also protect against installing anything named “system”.

Moving core18 build to foundations

  • Goal is to move building of core snaps to foundations team so we can unify security fixes
  • All testing processes currently in place need to be preserved
  • Cannot go directly to candidate without testing processes approving first
  • Foundation snaps will be pushed first on a separate track, then get to candidate and stable
  • Upgrades of core devices need to be figured out separately
  • Any patched packages to be gradually integrated into the archive
  • We might get core16 and core18 moved to foundations first, and then shrink core into irrelevance

So they… what?

Can we make the ubuntu core/base snaps be called something with an ubuntu prefix? The fact that we have only one store where everything lives means that once I get to having a Fedora-based core snap and Fedora base snap, I’d like to be able to configure snapd to use those on Fedora systems…

Sorry, fixed.

The core name is historical and doesn’t seem worth changing now. That said, note that base snaps work a bit differently than what’s suggested there. What decides the base snap to use is the snap itself, not the system it’s running on. That’s critical for the application to continue working correctly across distributions. So if a snap is installed in Fedora, it should continue using whatever core it was built with as a base. Same happens anywhere else: if a snap is built on Fedora with fedora28 (or something) as a base, and the snap is then installed in Ubuntu, snapd will pull fedora28 in and respect its base selection.

wouldnt that be the same on all systems (the “snapd snap” …)

you would only want a fedora-base snap and that you can name as you like …

Entitlements / Powers

  • Work is being deferred as the primary requirement is gone.
  • Design is still looking reasonable.
  • We’ll focus on the full implementation later, instead of rushing it now.


  • Works continues on the new store API that is a pre-requisite for epochs
  • Work on epochs specifically to be resumed in about a month.

Parallel installs

  • Will allow snaps to be installed as postgres_prod and postgres_stage, with prod and stage being local keys for the same underlying snap name.
  • There’s no need for any further commands to manipulate such suffixes, every command will work as usual while supporting the adorned name, as in snap install postgres_prod
  • Each installation has completely independent data: version, revision, track, configuration, etc.
  • Commands show the details in context for the given installation, as in snap info postgres_prod showing the exact revision and refresh details for that snap
  • The unadorned name still works, of course, with all existing semantics preserved
  • Bases, kernels, gadgets, will require an unadorned name to be present in the system, and that’s the one that snapd will look into for system-level activities.
  • The store API must get some sort of identifier for each snap (probably a sequence number) so that snapd and the store can communicate about the multiple instances. That identifier is specific to a single API call.
  • The suffix must be constrained so it encourages a small number of chars (probably just [a-z0-9]+), and it must not allow over 10 chars in the first implementation.

Upcoming releases

  • 2.32 was to be released until next Monday
  • Bug in layouts will push out release by a week
  • 2.33 will be difficult to ship in time for Ubuntu 18.04