systemd: enable sshkeys unit on supported platforms

[rfairley]

Add ConditionKernelCommandLine triggering conditions so that
the [email protected] unit is enabled only when recognized
cloud platforms are specified through ignition.platform.id.

For now, these platforms are azure and packet which are
currently supported in the afterburn-checkin and
afterburn-firstboot-checkin services.

Part of: coreos/fedora-coreos-tracker#4

[rfairley]

Tested on FCOS - this avoids an error when using a non-cloud platform such as qemu when [email protected] is enabled (coreos/fedora-coreos-tracker#4 (comment)).

I wonder if we should go ahead and enable all the supported platforms that are listed in the README. For FCOS however, some values of ignition.platform.id are different (e.g. the buildextend-openstack script adds the karg ignition.platform.id=openstack whereas the supported platform in Afterburn is identified by ignition.platform.id=openstack-metadata).

Alternatively this could go the other way, e.g. add a condition ConditionKernelCommandLine=!ignition.platform.id=qemu.

[bgilbert]

For the record, we didn't have this problem on Container Linux because the sshkeys service was enabled by the OEM-specific Ignition config. Your approach is a better way to do this, though.

We should add all the platforms for which Afterburn supports retrieving SSH keys. You're right that OpenStack and CloudStack are a problem, though. Afterburn providers are intentionally not the same as Ignition platforms. The expected flow for these platforms is that the user will tell CT that they're on openstack-metadata or cloudstack-configdrive, and CT will have Ignition write a drop-in which sets AFTERBURN_OPT_PROVIDER to --provider=<provider>. From a quick look at the CL OEMs, though, I'm not sure that CL even enables the sshkeys service on those platforms.

On FCOS... maybe CT should add the triggering condition on those platforms, since it's writing a drop-in anyway? @ajeddeloh?

[ajeddeloh]

CT adding the platform specific makes sense to me, but I'm also fine with this. Given CT doesn't quite exist yet I'm in favor of merging this now and possibly revisiting it later?

[bgilbert]

I was suggesting having CT handle it for the specific cases where Afterburn can't run without CT writing a drop-in first. So this PR would add triggering conditions for every provider except CloudStack, OpenStack, and VirtualBox (which doesn't support SSH keys).

[ajeddeloh]

Ah, gotcha. Works for me.

[rfairley]

The expected flow for these platforms is that the user will tell CT that they're on openstack-metadata or cloudstack-configdrive, and CT will have Ignition write a drop-in which sets AFTERBURN_OPT_PROVIDER to --provider=

This clarifies the difference a lot - thanks!

So this PR would add triggering conditions for every provider except CloudStack, OpenStack, and VirtualBox (which doesn't support SSH keys).

Makes sense - will update the PR for this.

[rfairley]

Updated (also updated the commit message)!

[lucab]

@bgilbert just to be clear, your plan here is for CT to write both a --provider=openstack-metadata dropin and a ConditionKernelCommandLine=|ignition.platform.id=openstack one, correct?

[bgilbert]

@lucab I was thinking both directives would be in the same drop-in, but yes.

[jlebon]

I posted a follow-up in #218 to solidify my understanding of how all this will get wired up.