Refresh information surfacing

With the new “refresh-schedule” branch close to be ready it would be nice to have an easy way to surface some information about the refreshes, i.e. when the last refresh happend, when the next refresh will happen and the current schedule.

Here are some ideas:

$ snap refresh --info
refresh-schedule: 00:00-04:59/5:00-10:59/11:00-16:59/17:00-23:59
last-refresh: 2017-04-25 12:18
next-refresh: 2017-04-25 18:53

$ snap info
potentially-more-useful: information
refresh-schedule: 00:00-04:59/5:00-10:59/11:00-16:59/17:00-23:59
last-refresh: 2017-04-25 12:18
next-refresh: 2017-04-25 18:53

Given that I have no real additional use-cases for a generic snap info I think the first version makes more sense.

2 Likes

I personally like the --info option to snap refresh. It is both contextual and obvious what the user is doing. snap info on the other hand operates on a per snap basis and does not (currently) give a system-wide view (and I don’t think it should). We could extend this to include snap refresh foo --info for per-snap refresh information if we are allowing per-snap scheduled refreshes.

First version looks better indeed.

Some trivial suggestions on top of it:

$ snap refresh --time
schedule: 00:00-04:59/5:00-10:59/11:00-16:59/17:00-23:59
last: 2017-04-25 12:18
next: 2017-04-25 18:53

(update: --when to --time)

The one thing with using --time is that is does not sit easily with the concept of dates so, if in future we want to allow a refresh to be scheduled on another date, --time seems a little counter-intuitive. To me --info opens up the possibility to use this convention for other commands where it makes sense.

To me a flag that was exactly matching what it was I was looking for would make most sense.

Something like: snap refresh --next or snap refresh --schedule Of course if this refresh info was available under snap refresh --info might not be needed.

I’ve wondered when the next scheduled update was many times. So this command would be amazing to have :grin:

In computing it’s common to see “time” including the idea of date. Think of “timestamp”, “epoch time”, Go’s time.Time, etc.

The second part of the rationale provided is actually a reason not to do it. For example, where would one find the history of refreshes? snap refresh --info? Maybe… the name seems appropriate, but it’s not there.

I implemented the snap refresh --time suggestion on top of the existing internal-refresh-schedule in https://github.com/snapcore/snapd/compare/master...mvo5:feature/internal-refresh-schedule-info?expand=1 - once the internal-refresh-schedule branch lands I will proposed this too.

Here is what it looks like currently:

$ snap refresh --time
schedule: 00:00-04:59/5:00-10:59/11:00-16:59/17:00-23:59
last: 2017-04-25 17:35:00 +0200 CEST
next: 2017-04-26 00:58:00 +0200 CEST

The branch the implements this is now ready for review at: https://github.com/snapcore/snapd/pull/3240

I had some questions about this feature - I’ve commented on the PR.