systemd: add packet-phone-home.service

[tormath1]

this service is triggered only on Equinix Metal / Packet instances.

[pothos]

Suggested change

	ExecStart=/usr/bin/curl --header "Content-Type: application/json" --request POST "${COREOS_PACKET_PHONE_HOME_URL}"
	ExecStart=/usr/bin/curl -fsSL --header "Content-Type: application/json" --request POST "${COREOS_PACKET_PHONE_HOME_URL}"

We should follow any redirection and also error on non-successful HTTP return codes

[pothos]

Suggested change

	EnvironmentFile=/run/metadata/flatcar
	Type=oneshot
	RemainAfterExit=yes
	EnvironmentFile=/run/metadata/flatcar

This should only run once

[tormath1]

Well, I think we should keep it as it was and let the service retries.

On QEMU, in the cloudinit* tests, we add in /etc a coreos-metadata.service which takes precedence over the one shipped in /usr. Since cloudinit runs "late", the first coreos-metadata.service required as a dependency of the packet-phone-home is started and this is one is failing because it actually wants to use afterburn -> the dependency fails -> packet-phone-home.service fails because of missing dependency (before evaluating the ConditionKernelCommandLine).

$ journalctl -u coreos-metadata.service
Sep 29 07:37:57 localhost systemd[1]: Starting coreos-metadata.service - Flatcar Metadata Agent...
Sep 29 07:37:57 localhost coreos-metadata[1266]: Error: failed to run
Sep 29 07:37:57 localhost coreos-metadata[1266]: Caused by:
Sep 29 07:37:57 localhost coreos-metadata[1266]:     0: fetching metadata from provider
Sep 29 07:37:57 localhost coreos-metadata[1266]:     1: unknown provider 'qemu'
Sep 29 07:37:57 localhost systemd[1]: coreos-metadata.service: Main process exited, code=exited, status=1/FAILURE
Sep 29 07:37:57 localhost systemd[1]: coreos-metadata.service: Failed with result 'exit-code'.
Sep 29 07:37:57 localhost systemd[1]: Failed to start coreos-metadata.service - Flatcar Metadata Agent.
Sep 29 07:37:58 core1 systemd[1]: coreos-metadata.service: Scheduled restart job, restart counter is at 1.
Sep 29 07:37:58 core1 systemd[1]: Stopped coreos-metadata.service - QEMU metadata agent.
Sep 29 07:37:58 core1 systemd[1]: Starting coreos-metadata.service - QEMU metadata agent...
Sep 29 07:37:58 core1 systemd[1]: coreos-metadata.service: Deactivated successfully.
Sep 29 07:37:58 core1 systemd[1]: Finished coreos-metadata.service - QEMU metadata agent.

We can't add a ConditionKernelCommandLine=!flatcar.oem.id=qemu on the coreos-metadata.service that we ship as this condition is not evaluated when the unit is a dependency of another one.

EDIT: Moving from Requires=coreos-metadata.service to Wants=coreos-metadata.service should be enough.

[pothos]

The service should still retry with RemainAfterExit=yes and Restart=on-failure, or?
I'm a confused, why is this related to qemu? It would be good to fix any dependency issues - Requires actually makes sense here.

[tormath1]

It does not retry as the failure is caused by systemd itself ("dependency failure"). It's related to QEMU because qemu is not a supported Afterburn platform, so the FIRST run of coreos-metadata (the one from /usr) is failing.

Yes, packet-phone-home is not supposed to run on qemu, and this is the case, but the ConditionKernelCommandLine is evaluated only at the execution and not before when the service (and its dependencies) are queued.

The conditions and asserts are checked at the time the queued start job is to be executed. The ordering dependencies are still respected, so other units are still pulled in and ordered as if this unit was successfully activated, and the conditions and asserts are executed the precise moment the unit would normally start and thus can validate system state after the units ordered before completed initialization. Use condition expressions for skipping units that do not apply to the local system, for example because the kernel or runtime environment doesn't require their functionality.

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Conditions%20and%20Asserts

Requires make sense but we have EnvironmentFile that actually makes fail the unit + it ensures that the unit run if the file is available.

[pothos]

Maybe we could still add conditions to coreos-metadata.service to prevent it from running. We know which platforms it supports and that would remove this unit failure from the logs.