group.of.nepali.translators team mailing list archive

[Dimitri John Ledkov <launchpad@xxxxxxxxxxxx>]

Public bug reported:

[ 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

** Affects: apt (Ubuntu)
     Importance: High
         Status: Triaged

** Affects: unattended-upgrades (Ubuntu)
     Importance: High
         Status: Triaged

** Affects: apt (Ubuntu Xenial)
     Importance: High
         Status: Triaged

** Affects: unattended-upgrades (Ubuntu Xenial)
     Importance: High
         Status: Triaged

** Affects: apt (Ubuntu Yakkety)
     Importance: High
         Status: Triaged

** Affects: unattended-upgrades (Ubuntu Yakkety)
     Importance: High
         Status: Triaged

** Affects: apt (Ubuntu Zesty)
     Importance: High
         Status: Triaged

** Affects: unattended-upgrades (Ubuntu Zesty)
     Importance: High
         Status: Triaged

** Affects: apt (Ubuntu Artful)
     Importance: High
         Status: Triaged

** Affects: unattended-upgrades (Ubuntu Artful)
     Importance: High
         Status: Triaged

** Also affects: apt (Ubuntu Yakkety)
   Importance: Undecided
       Status: New

** Also affects: apt (Ubuntu Artful)
   Importance: Undecided
       Status: New

** Also affects: apt (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: apt (Ubuntu Zesty)
   Importance: Undecided
       Status: New

** Changed in: apt (Ubuntu Xenial)
       Status: New => Triaged

** Changed in: apt (Ubuntu Yakkety)
       Status: New => Triaged

** Changed in: apt (Ubuntu Zesty)
       Status: New => Triaged

** Changed in: apt (Ubuntu Artful)
       Status: New => Triaged

** Changed in: apt (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: apt (Ubuntu Yakkety)
   Importance: Undecided => High

** Changed in: apt (Ubuntu Zesty)
   Importance: Undecided => High

** Changed in: apt (Ubuntu Artful)
   Importance: Undecided => High

** Description changed:

  [ 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
+  * unattended-upgrades are enabled by default in Ubuntu 16.04 and later
  
-  * For the long running instances, all of the above happens at random
- times throughout the day.
+  * 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
  
-  * If systems were poweredoff / suspended, this happens on boot / resume
+  * For the long running instances, all of the above happens at random 
+    times throughout the day.
  
-  * End-users would like to have predictable timing, and control over
- when the updates happen.
+  * 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.
+  * Decouple unattended-upgrades application, from apt update
  
-  * 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.
+  * 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.
+  * 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.
+  * 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.
+  * 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.
+  * 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.
+  * 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
+   * Related bug reports and history:
+     - bug #1615482
+     - bug #1554848

** Description changed:

  [ 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.
+  * 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.
+  * 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.
+      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.
+    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.
+  * 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.
+  * 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

** Also affects: unattended-upgrades (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: unattended-upgrades (Ubuntu Xenial)
       Status: New => Triaged

** Changed in: unattended-upgrades (Ubuntu Yakkety)
       Status: New => Triaged

** Changed in: unattended-upgrades (Ubuntu Zesty)
       Status: New => Triaged

** Changed in: unattended-upgrades (Ubuntu Artful)
       Status: New => Triaged

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: unattended-upgrades (Ubuntu Yakkety)
   Importance: Undecided => High

** Changed in: unattended-upgrades (Ubuntu Zesty)
   Importance: Undecided => High

** Changed in: unattended-upgrades (Ubuntu Artful)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1686470

Title:
  Apt updates that are uniformally spread across all timezones, with
  predictable application windows

Status in apt package in Ubuntu:
  Triaged
Status in unattended-upgrades package in Ubuntu:
  Triaged
Status in apt source package in Xenial:
  Triaged
Status in unattended-upgrades source package in Xenial:
  Triaged
Status in apt source package in Yakkety:
  Triaged
Status in unattended-upgrades source package in Yakkety:
  Triaged
Status in apt source package in Zesty:
  Triaged
Status in unattended-upgrades source package in Zesty:
  Triaged
Status in apt source package in Artful:
  Triaged
Status in unattended-upgrades source package in Artful:
  Triaged

Bug description:
  [ 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1686470/+subscriptions