summaryrefslogtreecommitdiff
path: root/systemd
diff options
context:
space:
mode:
authorJames Falcon <therealfalcon@gmail.com>2021-09-03 12:57:20 -0500
committerGitHub <noreply@github.com>2021-09-03 12:57:20 -0500
commite69a88745e37061e0ab0a1e67ad11015cca610c1 (patch)
tree1cc23126ce6eee277fd0e7661f1555c283dc22a8 /systemd
parent7fe0f900adcd45a74a24b7f9b251e2ee35b53b54 (diff)
downloadvyos-cloud-init-e69a88745e37061e0ab0a1e67ad11015cca610c1.tar.gz
vyos-cloud-init-e69a88745e37061e0ab0a1e67ad11015cca610c1.zip
Set Azure to only update metadata on BOOT_NEW_INSTANCE (#1006)
In #834, we refactored the handling of events for fetching new metadata. Previously, in Azure's __init__, the BOOT event was added to the update_events, so it was assumed that Azure required the standard BOOT behavior, which is to apply metadata twice every boot: once during local-init, then again during standard init phase. https://github.com/canonical/cloud-init/blob/21.2/cloudinit/sources/DataSourceAzure.py#L356 However, this line was effectively meaningless. After the metadata was fetched in local-init, it was then pickled out to disk. Because "update_events" was a class variable, the EventType.BOOT was not persisted into the pickle. When the pickle was then unpickled in the init phase, metadata did not get re-fetched because EventType.BOOT was not present, so Azure is effectely only BOOT_NEW_INSTANCE. Fetching metadata twice during boot causes some issue for pre-provisioning on Azure because updating metadata during re-provisioning will cause cloud-init to poll for reprovisiondata again in DataSourceAzure, which will infinitely return 404(reprovisiondata is deleted from IMDS after health signal was sent by cloud-init during init-local). This makes cloud-init stuck in 'init'
Diffstat (limited to 'systemd')
0 files changed, 0 insertions, 0 deletions