At the London sprint we sketched out a “global warnings” idea, that would enable snapd to alert users about situations that might otherwise pass unnoticed. Things like “you’re running low on disk space”. They could optionally be for a particular user (as sometimes the warning is something like “you need to log back in to the store because your credentials are now invalid” or similar).
Perhaps “system warnings” would be a better name for this, as “per-user global” seems strange.
Information about the warnings would piggyback on normal api responses, and while you’d be able to query them directly, they’d have thresholds about how often they’re expected to be shown to the user, and after how much time they’ll disappear from the system. There’ll only be one warning per message per user in the system (so you wouldn’t get spammed by hundreds of identical “you’re nearly out of space” messages); if a second message comes along with the same text, one of the timestamps in the existing message would be bumped but otherwise left alone.
So, what would this look like?
$ snap install xbill-xaw
xbill-xaw 2.1-xaw.1 from 'chipaca' installed
You have 3 unread warnings. To read them, see “snap warnings”.
that line might instead be
You have 1 new warnings (4 total). To read them, try “snap warnings”.
or perhaps if you only have one (but this one needs some more exploration),
Warning: Running out of available disk space. See “snap warnings”.
bottom line is, you interact with the system in some way, it tells you to go read your warnings.
$ snap warnings
Last seen Message
12h ago Was unable to contact store for weekly refresh.
2h ago Running out of available disk space.
1h ago Security threat detected on deck 4.
To acknowledge a warning and remove it from the list, see “snap okay”.
$ snap okay
Cleared warnings up to 13s ago.
From the commandline,
snap warnings would list active warnings and save the timestamp of the most recent message, and
snap okay would clear them using that timestamp, and the warnings shown to the user would use that timestamp for the “n new (m total)” message. Clients should probably collaborate on warnings, so that if the user clears them on the terminal, the gnome software doesn’t still show them. Paging robert.ancell.
For this to work the client needs to keep state, as the server doesn’t really know – it knows when it was asked, but not what the user got to see (in the same way that the client won’t really know either, but much more so). So far
snap is keeping its state in
~/.snap. This probably means we want to look at moving
~/.config/snapd (but remember
XDG_CONFIG_HOME) before implementing this (as that is something we want, and this would make the migration story worse).
A simpler approach might be to give each message an ID, and make you specify that ID to
snap okay (we wouldn’t be able to make
snap okay ack every warning, because a warning can get in between and get cleared without being read); this might get cumbersome (most users don’t know about Alt+*), less friendly (no way of reliably saying “n new warnings”), but would avoid having client-side state. On the other hand, we could do it as a first pass, to decouple warnings from the conf dir migration.
While most of the above looks at how the
snap interaction would be, we need to also make sure that it’s sane from a graphical desktop user’s perspective (e.g. is this something we’d want to expose via Gnome Software? Via an indicator, like the existing out-of-space check? something else), as well as from somebody consuming these warnings via monitoring tools like nagios or pagerduty.