Investigate making cloud-init → BOSH-agent network handoff explicit via service ordering (Azure) #791

PR cloudfoundry/bosh-agent#495 fixed an Azure-specific file-ordering collision between cloud-init/netplan's networkd profile and bosh-agent's profile by prefixing the BOSH file with 09-. During review, @s4heid suggested investigating whether the ownership contract between cloud-init and bosh-agent should be made more explicit in the service startup order.

Area for investigation

The current bosh-agent.service unit only declares After=network.target. There is no explicit dependency that ensures cloud-init has fully completed before bosh-agent applies its network configuration. If cloud-init runs again after bosh-agent (e.g. on certain Azure VM events), it could overwrite the networkd state bosh-agent set up.

bosh-agent.service lives at: stemcell_builder/stages/bosh_go_agent/assets/bosh-agent.service

The Azure init stage already uses a similar pattern for blocking cloud-config: stemcell_builder/stages/system_azure_init/assets/etc/systemd/system/cloud-config.service.d/firstboot-blocker.conf

It is worth investigating:

• Whether adding After=cloud-final.service to bosh-agent.service is safe and sufficient, or whether stronger constraints are needed.
• What the impact would be on IaaS providers where cloud-init is absent.
• Whether this interacts with the existing firstboot-blocker mechanism on Azure.

Related to: cloudfoundry/bosh-agent#500