snap upgrade hook

Bug #1611638 reported by Christian Ehrhardt 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Fix Released
High
Unassigned
snapd (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

On the a snapcraft ML I was asking about some sort of architectures way to process upgrades.

Somin Fells was so nice to reply with:
"For upgrades there will be a hook at some point in the near future which will notify
when your snap is upgraded and you can perform similar logic like you can do in the maintainer scripts to handle changed formts etc."

But after asking around no one knew about a bug to track that.
Especially for snappy on classic systems that upgrade processing will be needed for quite some packages to be able to be snap'ified.

Eventually the challenge is that regarding packages that need e.g. changed conffiles, templates, schemes, ... we will likely end up with one of:
a) patching the hell out of upstream projects which makes it either hard to be accepted or hard to maintain if ending up in sort of a delta
b) wrap all exposed binaries in wrappers
c) implementing at least a bit of upgrade processing to avoid a/b

I know there is some anxiety to the classic pre/post-inst/rm schema as being complex or error prone. But on the snappy world we don't have to go that far - since we have that nice versioned SNAP_USER_DATA/SNAP_DATA.
All that might be needed it a flag for a command that it has to be run automatically after upgrade of a snap. That could do the conversion on the "now new" versioned DATA path of the snap. Every other exposed binary of the snap will just work right away - no need for checkers a la "is it upgraded; no -> call upgrade handler, yes - call actual binary"

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Set whishlist as it is a feature

Changed in snapd (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

BTW - depending on the preferences of the snappy Team , such a "hook called after upgrade/install" would almost cover bug 1611287 as well (that hook could make things available). OTOH for 1611287 the point is that it doesn't even has to be installed as part of the snap but only into the DATA dirs.

Even if 1611287 would be solved via 1611638 there should be some sort of helper or library to do so, to avoid reimplementing the same helper over and over again in many snaps. Lessons learned from the deb world - that will one day lead to issues having to be fixed in just as many snaps then. While a provided helper by snappy would be one place to handle them all.

Anyway I wanted to point out that - if wanted architecture wise - those two bugs could be solved with one technical solution.

Revision history for this message
Leo Arias (elopio) wrote :
Changed in snapd (Ubuntu):
status: New → In Progress
Changed in snappy:
status: New → In Progress
assignee: nobody → Kyle Fazzari (kyrofa)
importance: Undecided → High
Revision history for this message
Kyle Fazzari (kyrofa) wrote :

The recommendation from Gustavo is to use the configure hook for this (which is run upon initial install, upgrade, and when `snap set` is called).

Changed in snappy:
assignee: Kyle Fazzari (kyrofa) → nobody
status: In Progress → New
Changed in snapd (Ubuntu):
status: In Progress → New
Revision history for this message
Simon Fels (morphis) wrote :

@Kyle: How is that supposed to work? Will there be an additional flag passed to the snap when the configure hook is called to indicate its called because of 'install' or 'upgrade' operations?

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Yeah I was reading https://github.com/snapcore/snapd/blob/master/docs/hooks.md and also wondered about how to differ install/upgrade - especially interesting as it was suggested to address bug 1611287.

I also would like to have the usual snap environment around like $SNAP_USER_DATA around, which - if already done - is at least not documented in the .md.

Revision history for this message
Kyle Fazzari (kyrofa) wrote :

@Simon: I'm not sure what the plan is, but I don't believe it passes anything extra at the moment. You could work around this by utilizing snapctl. For example, at the beginning of the hook, check `snapctl get installed`. If it's true, move on, but if it's false, run your initial install operations. Then set `snapctl set installed=true`.

You could do something similar with upgrades, save $SNAP_VERSION via `snapctl set version=$SNAP_VERSION` and then compare it to $SNAP_VERSION each time to determine if you're on a new version.

@Christian yes, hooks have the same environment and confinement as apps. Indeed, perhaps this should be documented more explicitly, thank you for the feedback.

Revision history for this message
Michael Vogt (mvo) wrote :

We have two hooks now - one that is run before the refresh happens and one after. This should cover this bug.

Changed in snapd (Ubuntu):
status: New → Triaged
affects: snappy → snapd
Changed in snapd:
status: New → Triaged
status: Triaged → Fix Committed
Changed in snapd (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Paweł Stołowski (stolowski) wrote :

Right. Just to clarify, the two new hooks are 'pre-refresh' and 'post-refresh'.

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

It seems that the hooks are available now so I'm marking this as fix released.

Changed in snapd (Ubuntu):
status: Fix Committed → Fix Released
Changed in snapd:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.