no cloud agents: packet

[dustymabe]

In #12 we decided that we'd like to try to not ship cloud agents. This ticket will document investigation and strategy for shipping without a cloud agent on the packet bare metal cloud platform.

See also #41 for a discussion of how to ship cloud specific bits using ignition.

[bgilbert]

Packet doesn't have an agent. The instance does need to report that the first boot was successful, but that only requires a single HTTP POST.

[bgilbert]

One other caveat: a machine's public IPv4 address is available via DHCP, but its private IPv4 and public IPv6 addresses are only available from the Packet metadata server. In Container Linux, coreos-metadata handles that now on first boot.

[dustymabe]

thanks @bgilbert for the info. So the single gap we have here is that we need to send out an HTTP POST on successful boot ? Should we create an Action Item for that? Do we need to do anything complicated like integrate with greenboot and only send out the HTTP POST on successful boot according to greenboot.

[bgilbert]

Yeah, we should probably integrate with greenboot on all platforms that require health checks at startup. Maybe that should look like a coreos-metadata subcommand that provides a consistent mechanism across platforms. I'll file an issue.

[bgilbert]

It appears that the necessary work is:

• Add mechanism for reporting instance health to cloud platforms afterburn#120
• Support cloud-specific grub fragments #110
• initramfs: support configuring network on DHCP-less platforms #111

Will PR the design doc.

[vielmetti]

Thanks for tackling this @bgilbert . Let me know if there are any gaps you see on the Packet side, and alert me when the design doc is ready to look at.

[vielmetti]

Several accounts were added to the Fedora CoreOS project at Packet; details at WorksOnArm/equinix-metal-arm64-cluster#110 . Happy to report back any progress, success, or challenges you have seen.

[dustymabe]

design doc PR: #130

[bgilbert]

On Container Linux on Packet, the core user is automatically logged in on the serial (SOS) console to ease troubleshooting. Fedora CoreOS could do something similar. Alternatively, we could automatically randomize the root password and pass it back to the Packet API, which would make it available for 24 hours (#110 (comment)).

In general, we'd like to avoid automatically logging in on console by default (#114 (comment)), and it seems inconsistent and surprising to automatically set a root password on only one platform. So let's plan not to automatically enable any sort of credential access for the SOS console. If users would like SOS access, they can use Ignition to enable autologin or to set a password on the core account; we'll document how to do that.

I've checked this plan with the Packet folks and they're okay with it.

[bgilbert]

New design doc PR in #133.