snap: add `snap refresh --time` option #3240

Merged
merged 109 commits into from May 4, 2017

Conversation

Projects
None yet
5 participants
Collaborator

mvo5 commented Apr 26, 2017

Based on #2833

This branch adds a new snap refresh --time option that will display information around the refresh times. This is useful for users to make things more transparent and also useful for debugging.

Here is the example output:

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

One thing I wonder about is if this information should be part of sysinfo or if we should create a dedicated endpoint. The branch is currently using sysinfo, but it seems a dedicated endpoint might be needed anyway when we implement something like snap refresh --delay 2h. Opinions welcome.

mvo5 and others added some commits Jan 31, 2017

reomove refresh.disabled as discussed during the standup, the tests w…
…ill use refresh.schedule in 2 days to disable the auto-refresh during the tests
the latest timeutil.Next() forces a refresh after 14 days, so we don'…
…t need to fiddle with the intervalls anymore
Merge branch 'feature/internal-refresh-schedule' of github.com:mvo5/s…
…nappy into feature/internal-refresh-schedule

+1 with a comment :-)

cmd/snap/cmd_snap_op.go
@@ -919,6 +941,7 @@ func init() {
waitDescs.also(channelDescs).also(modeDescs).also(map[string]string{
"revision": i18n.G("Refresh to the given revision"),
"list": i18n.G("Show available snaps for refresh"),
+ "time": i18n.G("Show auto refresh information"),
@chipaca

chipaca Apr 26, 2017

Member

I'd mention here that adding --time will not perform a refresh

@chipaca

chipaca Apr 26, 2017

Member

(I see that list has the same problem of not saying “this will not perform the action”)

@zyga

zyga Apr 26, 2017

Contributor
10:57 < mvo_> Chipaca: I like your suggestion about the --time help output. how about "Only show refresh time information" or "Only show refresh times information but not 
              perform any refresh"?
10:59 < zyga> mvo_: maybe `snap refresh --query` 

One question for Schedule.String below

cmd/snap/cmd_snap_op.go
@@ -919,6 +941,7 @@ func init() {
waitDescs.also(channelDescs).also(modeDescs).also(map[string]string{
"revision": i18n.G("Refresh to the given revision"),
"list": i18n.G("Show available snaps for refresh"),
+ "time": i18n.G("Show auto refresh information"),
@chipaca

chipaca Apr 26, 2017

Member

I'd mention here that adding --time will not perform a refresh

@chipaca

chipaca Apr 26, 2017

Member

(I see that list has the same problem of not saying “this will not perform the action”)

@zyga

zyga Apr 26, 2017

Contributor
10:57 < mvo_> Chipaca: I like your suggestion about the --time help output. how about "Only show refresh time information" or "Only show refresh times information but not 
              perform any refresh"?
10:59 < zyga> mvo_: maybe `snap refresh --query` 
timeutil/schedule.go
@@ -62,6 +66,13 @@ type Schedule struct {
Weekday string
}
+func (sched *Schedule) String() string {
+ if sched.Weekday == "" {
+ return fmt.Sprintf("%s:%s", sched.Start, sched.End)
@zyga

zyga Apr 26, 2017

Contributor

Is this a typo? The start:end vs start-end below?

@mvo5

mvo5 Apr 26, 2017

Collaborator

Yes, thank you very much for spotting this!

mvo5 added some commits Apr 26, 2017

tests/main/auto-refresh/task.yaml
break
fi
- sleep 1
+ echo "Doing something that triggers ensure"
+ snap install test-snapd-python-webserver
@zyga

zyga Apr 26, 2017

Contributor

Don't we have snap debug ensure-state-soon for this?

mvo5 added some commits Apr 26, 2017

@pedronis pedronis requested a review from niemeyer Apr 27, 2017

@@ -450,15 +450,23 @@ func autoRefreshInFlight(st *state.State) bool {
return false
}
-func lastRefresh(st *state.State) (time.Time, error) {
+func (m *SnapManager) LastRefresh() (time.Time, error) {
@pedronis

pedronis Apr 28, 2017

Contributor

they should grow a doc comment I think, that also explains they need to be used with the state lock

lgtm

Contributor

pedronis commented Apr 28, 2017

Personally I think it's fine to expose this on /system-info, and maybe/likely later repeat it on GET of some kind of /refresh(-schedule) endpoint as well, once we need an endpoint to control this as well

@chipaca chipaca merged commit cbd7b51 into snapcore:master May 4, 2017

5 of 6 checks passed

xenial-amd64 autopkgtest finished (failure)
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
xenial-i386 autopkgtest finished (success)
Details
xenial-ppc64el autopkgtest finished (success)
Details
yakkety-amd64 autopkgtest finished (success)
Details
zesty-amd64 autopkgtest finished (success)
Details
Contributor

robert-ancell commented Jun 14, 2017

I just noticed this change, I've put some documentation in https://github.com/snapcore/snapd/wiki/REST-API but a couple of questions:

  • The time formats are inconsistent with the rest of snapd - e.g. they don't match install-date from snap objects.

Only my system:
system-info: 2017-06-14 09:04:00 +1200 NZST
install-date: 2017-02-07T06:49:09+13:00

Could we change them to use the RFC3339 UTC format?

  • What format is the schedule in?
Contributor

robert-ancell commented Jun 26, 2017

PR for date formats #3528

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment