Comment 0 for bug 1686470

[ Impact ]

 * unattended-upgrades are enabled by default in Ubuntu 16.04 and later
 * Currently the following three things happen as a monolithic event:
   - metadata updates: apt update
   - download of updates: apt upgrade --download-only
   - application of updates: apt upgrade

 * For the long running instances, all of the above happens at random times throughout the day.

 * If systems were poweredoff / suspended, this happens on boot / resume

 * End-users would like to have predictable timing, and control over when the updates happen.

Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.

[ Proposed Default Behavior ]

 * Decouple unattended-upgrades application, from apt update

 * apt update:
   - shall be a systemd timer based unit, triggered every 12h with a
     random delay of 12h, therefore executed randomly twice a day.
   - if unattened-upgrades (default on), or download-upgreadaeble-packages
     are enabled, it should result in updates being downloaded aka
     `apt upgrade --download-only`

 * unattended-upgrades:
   - shall be a separate systemd timer based unit triggered at 6am local
     time with a random delay of 1h, therefore executed between 6am and 7am
     local time.

 * On boot / resume:
   - if we have missed one, or more, apt update timers,
     apt update / download upgrades / unattended-upgrade will happen in
     sequence. This may result in mirror spikes, but we do want to secure
     cold/stale-booted systems as soon as possible.

[Test Case]

 * Run system for more than 24h, and check that apt updates were
   automatically executed twice.

 * Check that unattended upgrades were triggered to be applied at
   6am..7am window, if any.

 * Poweroff the machine over the period when apt-get update was
   scheduled, poweron and observe that apt-get update / download / unattended
   upgrade are all performed on boot.

[Regression Potential]

 * The newly proposed behavior is a mix of Pre-xenial behavior of "do everything
   at 6am..6:30am window" and the xenial+ behavior of "do everything at random
   times throughout the day". If there are specific deployments that rely on the
   previous types of behaviour they will be able to adjust manually the systemd
   timers with the overrides to be executed exactly as they wish; or match the .0
   release behaviour that they preffer.

 * If timers behavior is coded wrongly the proposed behaviour might not be executed
   as intended, thus requiring further SRUs to bring us in-line with the great
   expectations.

[Other Info]

  * Related bug reports and history:
    - bug #1615482
    - bug #1554848