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

[rcj4747]

Filed in Ubuntu bug #1901033 as well.

We have an Ubuntu 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 use of the guest-agent package in older Ubuntu releases.

/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

[rbalint]

Those changes were added by downstream patches, thus the regression will be fixed in Ubuntu. This issue hopefully helps users triaging this problem.

[rcj4747]

Thank you @rbalint

As a workaround until our fix lands in Ubuntu packaging in Groovy (20.10) users can add cloud-init status --wait to the beginning of their startup script (as cloud-init does wait for snap seeding to complete).