Initial driver for the feature is holding refreshes right after seeding in some cases, but also a generally requested feature
snap refresh --hold=2h
Effective hold time is the maximum absolute time between current hold and requested hold
It does not schedule a refresh after the requested time, but instead prevents the refresh from happening within that window
Disabling the hold window is possible via --hold=none
Hold time is stored in refresh.hold core configuration setting (public)
Hold can change many times before the actual window without affecting it
At the refresh attempt, if inside a hold window, skip it as long as it doesn’t go beyond the maximum number of days (60 days right now)
Must warn if requested hold cannot be respected due to maximum period
In the future, per snap holds will be possible, but probably done via direct question to the snap (hook) instead of via persistent setting
First version of the --hold implementation will be optimistic and trust that nobody changed the configuration setting concurrently
On a follow up we’ll support configuration “nonces” (or version) that will allow optimistic locking of the configuration: “proceed as long as the config hasn’t changed since I looked”
The command work is pending, and recomputing next when inside the hold is also pending, but the underlying implementation is already up for review
