1

I am currently configuring a virtual machine to work as an agent within Azure (with Ubuntu as image). In which the additional configuration is running through a cloud init file.

In which, among others, I have the below 'fix' within bootcmd and multiple steps within runcmd.

However the machine already gives the state running within the azure portal, while still running the cloud configuration phase (cloud_config_modules). This has as a result pipelines see the machine as ready for usage while not everything is installed/configured yet and breaks.

I tried a couple of things which did not result in the desired effect. After which I stumbled on the following article/bug;

The proposed solution worked, however I switched to a rhel image and it stopped working. I noticed this image is not using walinuxagent as the solution states but waagent, so I tried to replacing that like the example below without any success.

bootcmd:
- mkdir -p /etc/systemd/system/waagent.service.d
- echo "[Unit]\nAfter=cloud-final.service" > /etc/systemd/system/waagent.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

After this, also tried to set the runcmd steps to the bootcmd steps. This resulted in a boot which took ages and eventually froze.


Since I am not that familiar with rhel and Linux overall, I wanted to ask help if anyone might have some suggestions which I can additionally try.

(Apply some other configuration to ensure await on the cloud-final.service within a waagent?)

Revils
  • 1,478
  • 1
  • 14
  • 31

2 Answers2

0

However the machine already had the state running, while still running the cloud configuration phase (cloud_config_modules).

Could you please be more specific? Where did you read the machine state?

The reason I ask is that cloud-init status will report status: running until cloud-init is done running, at which point it will report status: done

I what is the purpose of waiting until cloud-init is done? I'm not sure exactly what you are expecting to happen, but here are a couple of things that might help.

If you want to execute a script "at the end" of cloud-init initialization, you could put the script directly in runcmd, and if you want to wait for cloud-init in an external script you could do cloud-init status --wait, which will print a visual indicator and eventually return once cloud-init is complete.

Brett Holman
  • 743
  • 6
  • 18
  • I appended additional information as to your questions – Revils May 17 '22 at 06:25
  • I also tried to add cloud-init status --wait within the bootcmd, this resulted in the same situation; Giving status ready within the azure portal and after that running cloud init – Revils May 17 '22 at 06:39
  • Running cloud-init status --wait inside bootcmd or runcmd will deadlock, since it's waiting on itself. Don't do that. – Brett Holman May 18 '22 at 13:57
0

On not too old Azure Linux VM images, cloud-init rather than WALinuxAgent acts as the VM provisioner. The VM is marked provisioned by the Azure cloud-init datasource module very early during cloud-init processing (source), before any cloud-init modules configurable with user data. WALinuxAgent is only responsible for provisioning Azure VM extensions. It does not appear to be possible to delay sending the 'VM ready' signal to Azure without modifying the VM image and patching the source code of cloud-init Azure datasource.

Anton Tykhyy
  • 19,370
  • 5
  • 54
  • 56