Ticket #469 (closed enhancement: wontfix)
auto-update should get its desync interval, and possibly other info, from a URL
Reported by: | jdreed | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | Summer 2010 (Lucid Deploy) |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description
When we switched to a 6-hour desync schedule during busy periods, we lost the ability to push out updates quickly. I think we want this back, particularly if we break printing again.
While the existing desync intervals (6 hours "during the day", 2 hours otherwise) are fine as fallbacks, I want the auto updater to go check a URL for a suggested desync interval. If fetching the URL fails, it can fallback to the existing schedule. We undoubtedly want to take #309 into account when implementing this.
Alternatively, the only real reason we want to desync updates is to avoid the suckage of huge updates (texlive, OOo, etc). We had talked about a URL providing a whitelist of packages that should be updated immediately, so that we can fix, say, reactivate and printing-config instantaneously. The danger there is that we can also deploy broken packages instantaneously.
This description should be updated to reflect whichever method we chose for regaining some measure of control over auto-updates.
Change History
comment:2 Changed 14 years ago by jdreed
- Status changed from new to closed
- Resolution set to wontfix
I think what we actually want here is a package whitelist of things that should always be taken, so we can quickly fix things we break in the cluster environment. Perhaps when we fix #309, we can make auto-update run every 2 hours, and maybe take a few select packages (auto-update, reactivate, c-l-c, etc) regardless of whether it's "time to update" or not.
The problem with using a URL is that your web server is potentially also vulnerable to a lack of desynchronization. If you have 1000+ clients querying it even for a single static web page, you may want at least a little desyncing there.