[BUG] WALinuxAgent service should start after the cloud-config service

Currently (On Canonical UbuntuServer 18.04-LTS) the WALinuxAgent service and cloud-init run in parallel on start-up causing issues with contention of the package repository.

I believe that WALinuxAgent should start after the cloud-config service to ensure that:

• Packages that extensions may depend on can be installed by cloud-init; (EG: https://github.com/microsoft/azure-pipelines-agent/issues/2866 for an example)
• Updates or packages installed by WALinuxAgent, or by Extensions, do not contend for the distribution’s package manager, causing locks and failures

Distro and WALinuxAgent details:

• Distro and Version: [e.g. Ubuntu 18.04 latest image]
• WALinuxAgent version

WALinuxAgent-2.2.45 running on ubuntu 18.04
Python: 3.6.9
Goal state agent: 2.2.48.1

Additional context My current situation when starting an Ubuntu 18.04 VM, with the Log Analytics extension is that:

1. WALinuxAgent starts, installs the Log Analytics agent (through extension) then;
2. Shortly after (~2 seconds or so) cloud-init starts with the following configuration:

package_upgrade: true
package_reboot_if_required: true

1. WALinuxAgent or Log Analytics agent has the package repository lock, and causes cloud-init to fail

My current solution is to modify the service behaviour by adding this override to /etc/systemd/system/walinuxagent.service.d/override.conf from within bootcmd using cloud-init:

[Unit]
After=cloud-config.service

[carldjohnston]

Update on this; my proposed solution doesn’t appear to work reliably.

I believe that the walinuxagent service needs to start after cloud-final to be more robust. I’m achieving that with the following in cloud-init:

bootcmd:
  - mkdir -p /etc/systemd/system/walinuxagent.service.d
  - echo "[Unit]\nAfter=cloud-final.service" > /etc/systemd/system/walinuxagent.service.d/override.conf
  - sed "s/After=multi-user.target//g" /lib/systemd/system/cloud-final.service > /etc/systemd/system/cloud-final.service
  - systemctl daemon-reload

[ma-armenta]

Good workaround but this should be fix, or allow extension sequencing for customScript extension.