@brendan.carroll Indeed. We’ll definitely be implementing the proposal above soon, and it will address that. Our current plan is to enable scheduling on one or more days of the week within the month (e.g. 2nd Tuesday, between 9am and 10am).
As an aside, note that even for large snaps the downloads are actually deltas on top of the local revision
@cratliff Of course. There are at least three different features that cover the detailed scheduling:
- One or more precise time windows may be defined for the whole system to update under. Today that window is constrained to a daily basis, and we’re changing that so that it may be scheduled to one or more days of the week within the month, per the example above.
- Soon we’ll also enable the administrator to explicitly defer a scheduled update so that it doesn’t happen in the next so many hours or days. There will be a limit to the postponing, but it’ll be non-trivial (probably over a month).
- Then, snaps will also have a saying on whether it is a good time or not for an update to happen. There are many cases which can easily benefit from scheduled updates, but have strict windows in which they cannot happen. For example, Spotify is being used right now to listen to music, so don’t update it.
As for health checks, the snap will be able to define a hook that verifies whether the snap is working well after the update. This may hold arbitrary logic. If the health check fails, the snap will be automatically reverted. This same mechanism will also be used to implement canary rollouts, in which a controlled number of systems is updated and if a relevant number of them report a failure, the upgrade is stopped and the status is reported back to the snap publisher.
Yes, there will certainly be management platforms for controlling site-wide deployments, but that falls slightly outside of the scope of the core snapd project itself.
@jacobgkau There are a number of valid concerns about auto-updates that we’re trying to address, but I don’t see how this particular problem is made any worse with auto-updates or how we might even do much about at all, in the sense that there will always be an element of trust on the publisher of the snap no matter what we do. In other words, whether you manually update or automatically update a snap, for using the snap at all you have to trust that the developer is not simply shipping your private conversations to arbitrary third-parties for example, in the case of a chat service.
With or without auto-update the publisher might add such a backdoor on the next update, and that backdoor will remain there for as long as that update is installed on your system, which means at least 3 months to review the backdoor assuming the auto-update scheme above since we keep three revisions around, and you may always just copy it out onto a separate space to review in the future.
So the situation is really not that different from a manual update.
@mwinter Yeah, some of the features above are aimed at such scenarios.
Right, that’s indeed the purpose of tracks. There are more details in this topic.
As for examples, I suggest having a look at the requests in the store category.