Merge ~awe/snappy-hwe-snaps/+git/network-manager:snap-update-20-epoch into ~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager:snap-20

Proposed by Tony Espy
Status: Merged
Approved by: Alfonso Sanchez-Beato
Approved revision: bd2e479614ec595050aaf4f0f63f6aec12adc095
Merged at revision: eaa6f8f4cdce47a8f3ae282da53d690956df8fb5
Proposed branch: ~awe/snappy-hwe-snaps/+git/network-manager:snap-update-20-epoch
Merge into: ~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager:snap-20
Diff against target: 51 lines (+19/-4)
2 files modified
snap/snapcraft.yaml (+10/-0)
tests/lib/utilities.sh (+9/-4)
Reviewer Review Type Date Requested Status
Alfonso Sanchez-Beato Approve
Heather Ellsworth (community) Approve
System Enablement Bot continuous-integration Approve
Review via email: mp+399241@code.launchpad.net

Description of the change

Since the uc20 version of the network-manager snap has been updated to default to the native netplan configuration plugin, it's no longer possible to refresh from an earlier track, as the format and location of system-connection files have changed.

If it's decided at some point in the future that cross-track refreshes need to be supported, then logic will need to be added to the post-refresh hook to handle conversion of the connection files, and the epoch adjusted accordingly to reflect this.

Tested on a Dell Edge 3000 with network-manager 1.2.2-28 (615) installed:

$ snap list | grep network
network-manager 1.2.2-28 615 latest/stable canonical* -
admin@C2112XX:~$ sudo snap install network-manager_1.22.10-5-dev_amd64.snap --dangerous
error: cannot install snap file: cannot refresh "network-manager" to local snap with epoch 1,
       because it can't read the current epoch of 0

To post a comment you must log in.
Revision history for this message
System Enablement Bot (system-enablement-ci-bot) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Heather Ellsworth (hellsworth) wrote :

The system-enablement-ci-bot error is because of the use of epoch 1.

Do we need to use epochs here? I think epochs are just another way of controlling what versions a user auto-updates, but wouldn't it be sufficient to just put the current snap into 20/beta? I thought that was what we decided yesterday.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

I think using epochs is appropriate, we can move to 'epoch: 1*' when/if we have hooks ready to do system connections conversion. In any case the tests need to be fixed.

Revision history for this message
Tony Espy (awe) wrote :

@Heather

Per our discussion last week, the epoch prevents someone from refreshing from an earlier version of the snap where the keyfile plugin is being used for system-connections. If they updated to the uc20 version, they'd lose all of their connections.

Also @Alfonso explained, if we decide that this is something we want to support, then we need to implement the conversion logic in the post-install hook, and then set the epoch to "1*".

@Alfonso, I'll fix the test(s).

Revision history for this message
System Enablement Bot (system-enablement-ci-bot) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
System Enablement Bot (system-enablement-ci-bot) wrote :
review: Approve (continuous-integration)
Revision history for this message
Heather Ellsworth (hellsworth) wrote :

looks good to me!

review: Approve
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

LGTM

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1diff --git a/snap/snapcraft.yaml b/snap/snapcraft.yaml
2index 8a3e167..0b858fb 100644
3--- a/snap/snapcraft.yaml
4+++ b/snap/snapcraft.yaml
5@@ -13,6 +13,16 @@ base: core20
6 confinement: strict
7 grade: stable
8
9+# Since the uc20 network-manager snap currently defaults to the native
10+# netplan config plugin, the default format of connection files has
11+# switched from keyfile to netplan, thus a fresh from earlier tracks
12+# of network-manager will not work w/out post-refresh hook support to
13+# handle conversion of system connection files. For this reason, this
14+# version of the network-manager snap declares the epoch 1. If/when
15+# support is added to convert from keyfile to netplan, then the epoch
16+# will be adjusted accordingly.
17+epoch: 1
18+
19 slots:
20 service: network-manager
21
22diff --git a/tests/lib/utilities.sh b/tests/lib/utilities.sh
23index ce6ca0e..b068085 100644
24--- a/tests/lib/utilities.sh
25+++ b/tests/lib/utilities.sh
26@@ -1,5 +1,13 @@
27 #!/bin/bash
28
29+snap_connect_ifaces() {
30+ snap connect network-manager:firewall-control :firewall-control
31+ snap connect network-manager:network :network
32+ snap connect network-manager:network-setup-observe :network-setup-observe
33+ snap connect network-manager:ppp :ppp
34+ snap connect network-manager:nmcli network-manager:service
35+}
36+
37 snap_install() {
38 name=$1
39 if [ -n "$SNAP_CHANNEL" ] ; then
40@@ -8,11 +16,8 @@ snap_install() {
41 snap install --$SNAP_CHANNEL $name
42 fi
43 else
44- # Need first install from store to get all necessary assertions into
45- # place. Second local install will then bring in our locally built
46- # snap.
47- snap install $name $2
48 snap install --dangerous $PROJECT_PATH/$name*_amd64.snap
49+ snap_connect_ifaces
50 fi
51 }
52

Subscribers

People subscribed via source and target branches