[SRU] 2.11

Bug #1605303 reported by Michael Vogt on 2016-07-21
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned

Bug Description

This is a new version of snapd.

The changelog for 2.11 is available here https://github.com/snapcore/snapd/blob/2.11/debian/changelog, the raw git changelog is available here: https://github.com/snapcore/snapd/commits/2.11 (note that the debian changelog is auto-generated from the merges of the git commits so there is usually no need to look at the raw git commits).

The snappy team released a new 2.11 micro release that we want SRU into xenial. The new process described in https://wiki.ubuntu.com/SnapdUpdates was used and we have done integration-tests on the snappy images, autopkgtests on classic and unit tests.

The following automatic tests are run:
- travis unit tests https://travis-ci.org/snapcore/snapd/branches (check for 2.11 here)
- travis/spread based integration/system tests: https://travis-ci.org/snapcore/snapd/branches (check for 2.11 here under "spread")
- jenkins autopkgtests http://162.213.35.179:8080/job/snappy-by-tag-autopkgtest/13/
- jenkins integration tests: http://162.213.35.179:8080/job/snappy-by-tag-integration-test/16/

The following additional tests were performed:
"""
- adt-buildvm-ubuntu-cloud
- customize the resulting image: "sudo apt install snapd && sudo snap install hello-world && hello-world.env && sudo snap remove hello-world" (ensures the base image has the old debs and the daemon has some state)
- adt-run --source snapd_2.11.dsc --- adt-virt-qemu adt-xenial-amd64-cloud.img: PASS
"""
This included the upgrade from 2.0.10 as part of the autopkgtest run. There are also various snaps installed/removed (including installing and running ubuntu-calculator-app in xvfb) and run as part of the auto pkg test, including reboots to ensure that the system keeps working over reboots.

After installing the new snapd it was ensured that apt is unaffected by doing:
"""
- sudo apt install -y hello && sudo apt remove -y hello
"""

After installing the new snapd gnome-software was used:
"""
- install "http" (snap) and remove it again
"""
All worked as expected.

Sebastien Bacher (seb128) wrote :

the changelog urls you gave are 404

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu Xenial):
status: New → Confirmed
Changed in snapd (Ubuntu):
status: New → Confirmed
Changed in snapd (Ubuntu):
status: Confirmed → New
Changed in snapd (Ubuntu Xenial):
status: Confirmed → New
Michael Vogt (mvo) on 2016-07-26
summary: - [SRU] 2.0.11
+ [SRU] 2.11
Michael Vogt (mvo) on 2016-07-26
description: updated
Andy Whitcroft (apw) wrote :

This blind assumption that all units starting with snap[-.] are ours to do with as we see fit seems suspect. snapd does not own the snap prefix exclusively. We could imagine a package with a snap-shotting-service.service which would now get randomly stopped when snapd is removed:

+ mounts="$(systemctl list-unit-files | grep '^snap[-.].*\.mount' | cut -f1 -d ' ')"
+ services="$(systemctl list-unit-files | grep '^snap[-.].*\.service' | cut -f1 -d ' ')"

As we are making these dynamically can we not record them or tag them internally so we are sure they are ours? Or perhaps make them symlinks to somewhere else so we can positively identify the ones which we made.

Changed in snapd (Ubuntu Xenial):
status: New → Incomplete
Adam Conrad (adconrad) wrote :

Following up on Andy's comment above (which may or may not have been cargo-cult from an IRC conversation we had), I think a sane approach would be:

1) Create unit files in /var/snap/systemd/foo.{mount,service}
2) Symlink /etc/systemd/system/foo -> /var/snap/systemd/foo

On postrm/purge, you can then do the same list-unit-files trick, but:

1) readlink /etc/systemd/system/foo
2) iff symlink points to /var/snap/systemd/*, remove.

That way, you're not claiming absolutely dominion over a namespace that other packages or the sysadmin may have other ideas about.

Andy Whitcroft (apw) wrote :

I am also concerned about the gratuitious removal of /snap wholesale. It is not unheard of to use /snap as a snapshot directory for filesystems such as zfs and btrfs.

Andy Whitcroft (apw) wrote :

I wonder if we could check for /snap and indeed /var/snap existing in preinst and abort if they exist. Then once we are installed we know they are our at least.

Andy's suggestion makes sense.

Should we also kick off a thread around adding /snap to the FHS?

Mark

Zygmunt Krynicki (zyga) wrote :

> Wiadomość napisana przez Mark Shuttleworth <email address hidden> w dniu 27.07.2016, o godz. 08:38:
>
> Andy's suggestion makes sense.
>
> Should we also kick off a thread around adding /snap to the FHS?

I’ll start looking at this.

Best regards
ZK

Launchpad Janitor (janitor) wrote :
Download full text (6.5 KiB)

This bug was fixed in the package snapd - 2.11+16.10

---------------
snapd (2.11+16.10) yakkety; urgency=medium

  * New upstream release: LP: #1605303
    - increase version number to reflect the nature of the update
      better
    - store, daemon, client, cmd/snap, docs/rest.md: adieu search
      grammar
    - debian: move snapd.refresh.timer into timers.target
    - snapstate: add daemon-reload to fix autopkgtest on yakkety
    - Interfaces: hardware-observe
    - snap: rework the output after a snap operation
    - daemon, cmd/snap: refresh --devmode
    - store, daemon, client, cmd/snap: implement `snap find --private`
    - tests: add network-observe interface spread test
    - interfaces/builtin: allow getsockopt for connected x11 plugs
    - osutil: check for nogrup instead of adm
    - store: small cleanups (more needed)
    - snap/squashfs: fix test not to hardcode snap size
    - client,cmd/snap: cleanup cmd/snap test suite, add extra args
      testThis cleans up the cmd/snap test suite:
    - wrappers: map "never" restart condition to "no."
    - wrappers: run update-desktop-database after add/remove of desktop
      files
    - release: work around elementary mistake
    - many: remove all traces of channel from the buying codepath
    - store: kill setUbuntuStoreHeaders
    - docs: add payment methods documentation
    - many: present user with a choice of payment backends
    - asserts: add cross checks for snap asserts
    - cmd/snap,cmd/snap-exec: support running hooks via snap-exec.
    - tests: improve snap run symlink tests
    - tests: add content sharing interface spread test
    - store & many: a mechanical branch shortening store names
    - snappy: remove old snappy pkg
    - overlord/snapstate: kill flagscompat
    - overlord/snapstate, daemon, client, cmd/snap: devmode override
      (aka confined)
    - tests: extend refresh test to talk to the staging and production
      stores
    - asserts,daemon: cross checks for account and account-key
      assertions
    - client: existing JSON fixtures uses tabs for indentation
    - snap-exec: add proper integration test for snap-exec
    - spread.yaml, tests: replace hello-world with test-snapd-tools
    - tests: add locale-control interface spread test
    - tests: add mount-observe interface spread test
    - tests: add system-observe interface spread test
    - many: add AuthContext to mediate user updates to the state
    - store/auth: add helper for the macaroon refresh endpoint
    - cmd: add buy command
    - overlord: switch snapstate.Update to use ListRefresh (aka
      /snaps/metadata)
    - snap-exec: fix silly off-by-one error
    - tests: stop using hello-world.echo in the tests
    - tests: add env command to test-snapd-tools
    - classic: remove (most of) "classic" mode, this is implemented as a
      snap now
    - many: remove snapstate.Candidate and other cleanups
    - many: removed authenticator, store gets a user instead
    - asserts: fix minor doc comment typo
    - snap: ensure unknown arguments to `snap run` are ignored
    - overlord/auth: add Device/SetDevice to persist device identity in
      state
    - overlord: make SyncBoot work aga...

Read more...

Changed in snapd (Ubuntu):
status: New → Fix Released
Michael Vogt (mvo) wrote :

I pushed a branch at https://github.com/snapcore/snapd/pull/1606 that should address the concerns and add extra checks before removing the systemd units and also only removes directories that we know belongs to snaps under /snap and /var/snap. Please let me know if this looks sufficient.

Andy Whitcroft (apw) wrote :

@mvo -- that latest interim upload looks to remove the snapd.postrm which is relied upon by the tests. I think we need to rather revert it to the original from 2.0.11:

    diff -Nru snapd-2.0.10/debian/snapd.postrm
    snapd-2.11+0.16.04/debian/snapd.postrm
    --- snapd-2.0.10/debian/snapd.postrm 2016-06-29 19:03:11.000000000
    +0000
    +++ snapd-2.11+0.16.04/debian/snapd.postrm 1970-01-01
    00:00:00.000000000 +0000
    @@ -1,9 +0,0 @@
    -#!/bin/sh
    -
    -set -e
    -
    -if [ "$1" = "purge" ]; then
    - # FIXME: should we try to remove all snaps, mount points, services,
    - # mount units that got created as well?
    - rm -f /var/lib/snapd/state.json
    -fi
    \ No newline at end of file
[...]
    +# purge all state
    +sh ${SPREAD_PATH}/debian/snapd.postrm purge

Andy Whitcroft (apw) wrote :

The new checks for removal of bits in /snap et al proposed at the URL below look to address my concerns:

    https://github.com/snapcore/snapd/pull/1606

Hello Michael, or anyone else affected,

Accepted snapd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/snapd/2.11+0.16.04 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in snapd (Ubuntu Xenial):
status: Incomplete → Fix Committed
tags: added: verification-needed
Federico Gimenez (fgimenez) wrote :

Verification done following [1], all steps performed, specifically:

+ Executed manual tests described in [2] and [3]
+ Done exploratory testing (install/uninstall snaps, connect/disconnect interfaces, search, list)
+ Verified new features through automated tests
+ Verified actual upgrade from 2.0.10 to 2.11
+ Checked interaction with classic apt install and update of debs
+ Installed/uninstalled snaps and debs from gnome-software center

[1] https://wiki.ubuntu.com/SnapdUpdates
[2] https://github.com/snapcore/snapd/blob/master/integration-tests/manual-tests.md
[3] https://docs.google.com/spreadsheets/d/1EfjoPHmorG8A5jobzwmCIhAqI4N2zUTwDtA1JjgTn_c/edit#gid=0

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package snapd - 2.11+0.16.04

---------------
snapd (2.11+0.16.04) xenial; urgency=medium

  * debian/snapd.postrm:
    - remove purge for now to unblock the SRU (LP: #1605303)
  * spread.yaml:
    - reset previous "purge" for now

 -- Michael Vogt <email address hidden> Mon, 01 Aug 2016 15:45:21 +0200

Changed in snapd (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for snapd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers