** Description changed:

  [Impact]
  
  * We have a functional regression from gce-compute-image-packages to the
  new google-guest-agent. Without waiting for cloud-final and snapd.seeded
  we won't present a consistent system for users to run scripts that have
  archive mirrors set up, GCE's google-cloud-sdk snap installed, users in
  the proper groups, or other customizations owned by those services.
  
  [Test Case]
  
  * Observe google-startup-scripts waiting for snapd.seeded and cloud-
  final:
  
  root@rbalint-gg-1:~# systemd-analyze dot| egrep 
'google-startup-scripts.*(snapd\.seeded|cloud-final)'
-       "google-startup-scripts.service"->"snapd.seeded.service" 
[color="green"];
-       "google-startup-scripts.service"->"cloud-final.service" [color="green"];
-       "google-startup-scripts.service"->"cloud-final.service" 
[color="grey66"];
-       "google-startup-scripts.service"->"snapd.seeded.service" 
[color="grey66"];
-    Color legend: black     = Requires
-                  dark blue = Requisite
-                  dark grey = Wants
-                  red       = Conflicts
-                  green     = After
+  "google-startup-scripts.service"->"snapd.seeded.service" [color="green"];
+  "google-startup-scripts.service"->"cloud-final.service" [color="green"];
+  "google-startup-scripts.service"->"cloud-final.service" [color="grey66"];
+  "google-startup-scripts.service"->"snapd.seeded.service" [color="grey66"];
+    Color legend: black     = Requires
+                  dark blue = Requisite
+                  dark grey = Wants
+                  red       = Conflicts
+                  green     = After
  
  [Regression Potential]
  
  * The fix is adding missing dependencies for the services shipped in
  google-guest-agent. The same dependencies were added when gce-compute-
  image-packages shipped those services thus restoring them would cause
  issues, but in theory the added dependencies could introduce cycles
  making the service ordering unreliable. I have not seen any sign of such
  issue.
  
  [Original Bug Text]
  We have a cloud-images qualification test for google startup scripts to 
ensure that cloud-init customizations are available before the user startup 
script is run.  That test is failing and investigation shows that we have a 
functional regression from gce-compute-image-packages to the new 
google-guest-agent.  Without waiting for cloud-final and snapd.seeded we won't 
present a consistent system for users to run scripts that have archive mirrors 
set up, GCE's google-cloud-sdk snap installed, users in the proper groups, or 
other customizations owned by those services.  We are not holding groovy 
release on this bug, but we would like this treated with priority and it is a 
blocker for SRU.
  
  /usr/lib/systemd/system/google-startup-scripts.service in focal from
  gce-compute-image-packages:
  
  [Unit]
  Description=Google Compute Engine Startup Scripts
  After=network-online.target network.target rsyslog.service
  After=google-instance-setup.service google-network-daemon.service
  After=cloud-final.service multi-user.target
  Wants=cloud-final.service
  After=snapd.seeded.service
  Wants=snapd.seeded.service
  
  /usr/lib/systemd/system/google-startup-scripts.service in groovy from
  google-guest-agent:
  
  [Unit]
  Description=Google Compute Engine Startup Scripts
  Wants=network-online.target rsyslog.service
  After=network-online.target rsyslog.service google-guest-agent.service
  Before=apt-daily.service
+ 
+ ===
+ Workaround:
+ 
+ As a work-around users can add cloud-init status --wait to the beginning
+ of their startup script (as cloud-init does wait for snap seeding to
+ complete).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901033

Title:
  google-startup-scripts service no longer waits for cloud-
  init/snapd.seeded

To manage notifications about this bug go to:
https://bugs.launchpad.net/google-guest-agent/+bug/1901033/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to