The individual build pages on https://build.staging.snapcraft.io now instruct developers to install by revision. These instructions also state that the snap will not be auto-updated. Good! If I’m testing an automated build to see if that revision is promotable I definitely don’t want it getting updated under me.
But I was curious if there’s any path to updating in that situation, so I tried the following:
So it seems the only way to get refresh support for a snap installed by revision is to remove and reinstall it. This seems reasonable, but is it intentional? If so, I’ll note it in the documentation.
The described behavior doesn’t seem intended, and I also suspect that’s not quite what is going on there.
What’s likely happening is that snapd is holding back the refresh to the a revision that was already at the tip when you asked to install the older revision, so that your request isn’t just immediately undone. That’s similar to what happens when you use snap revert. Once a new revision shows up in the store, a refresh should take it into account and move on.
As a side note, the store should not allow arbitrary revisions to be used with --revision unless logged in as a developer of the respective snap. For everybody else, only those revisions actually published at the tip should be available, and perhaps older ones for a while so that there’s no breakage of on-going refreshes. I think we’re at least half-way there already, but not sure if the whole semantics were put in place yet (cc @noise@natalia).
The store should not allow access to a snap revision that is not released in a channel, to users that are not either publisher or collaborators. @evan or @niemeyer could you please file a bug in the snapstore project so we assign and work on this asap?
Regarding the on-going refreshes, I thought that snapd would be able to revert to an older (formerly installed) revision if there was any issue with the new revision returned by the metadata refresh check. Is this still the case? Does snapd really need the store to allow download of un-released revisions? (This is not accounting for update-validations which we are handling in other feature-thread).
@natalia To be clear, I’m not saying there is a bug yet. Just calling out the details to make sure we’re aligned.
So, outlining what I think we’re agreeing to in the form of a proposal:
Only publisher and developers of a given snap should have access to arbitrary revisions.
Reverts are only possible to already installed revisions, because reverting can’t be done without data
Three revisions are kept around by default on refreshes, which implies reverting to two of them is possible
Using –revision to refresh into those revisions is possible because they are already local
Using –revision to refresh or revert into a revision which was published into a channel in the past should not be possible, unless the revision is the tip of some channel or is part of an active refresh control statement.
Some grace period is necessary to implement 5 without breaking operations in progress.
Points 5 and 6 is where the current implementation might need work. The background there is that there’s no reason to allow access to ancient revisions, unless those revisions are at the tip of a channel or being referenced for explicit usage in some other way. With the new channels implementation there’s a lot of room to make ancient revisions properly available when that’s intended by the publisher/developer, so it seems best to not introduce more uncertainty.
To be clear, I’m the publisher of the snap in question. The workflow I think we need is:
I hook up automated builds to the edge channel of a snap I publish
I install the snap from edge by --revision to test a build that I’m considering for promotion
Nothing moves that revision out from under me while I test (i.e. no automatic refreshes to a newer revision)
If we agree that’s reasonable policy, the next thing to consider is whether installs by --revision stay there forever or can be put back on the automated path by an explicit snap refresh mailhog-ev.
Assuming I correctly understood your reply, the current behaviour means that if a new commit lands on master and a new revision ends up in edge, the revision I’m testing could be replaced midway through.
@niemeyer does this consider update control? With update control enabled, can device update to “approved” revision which will not be at the same time latest revision in the channel? At the moment update control also allows user to “force” install latest revision. So device sees at least two revisions.
I will be looking at this since I was involved in the new channels implementation. We agree with the given outline, and I’m working on making sure we satisfy the points above server-side.
I would need more details about this grace period you mention in 6, though. You mean that there should be a period in which a “just unpublished”[1] revision is still downloadable? searchable? (for non publisher/developers)
[1] unpublished: the revision is not available anymore in any channel
@evan Per our conversation in the call today, for the workflow you want we should implement the “postpone any refreshes by N hours” feature. This will ensure that things do not move under you in that moment in which you’re working on that snap, and it also supports “I’m watching a movie” or “I’m doing a presentation” cases. Also, in current master we already have support for scheduling refreshes to specific periods of the day, so this may solve most issues already if you schedule it for, say, 4-5AM.
@ondra Right, that’s refresh control listed in point 5.
@matiasb That’s great news, thank you! Point 6 is about having in mind that the world is moving on while somebody does such atomic update operations, so for a short while we should still allow downloads to succeed since they may be performed based on details that were just consulted prior to the tip change. This may be a pretty short period, though, because snapd won’t cache such download URLs anywhere. We can start with, say, one hour, giving time for people that have had access to the details to finish their downloads. Searches and other consulting APIs should reflect the tip changes immediately, though. This is really just about not breaking the user experience after an atomic change.
For the record, this outline has been confirmed and missing details were implemented. Changes are already deployed to production. The grace period for 6. was set to 1h.
I think we can mark this solved and keep discussing the other bits (postpone refresh, refresh control) in specific threads, if needed.
