afterburn docs: record cloud-specific quirks

Cloud providers may have specific quirks and restrictions which could result in surprising behaviors of coreos-metadata or which could require workarounds in the codebase. Those should be documented in the repository, so that we have an explicit note to reference.

The first example of this has been reported at https://github.com/coreos/bugs/issues/2468#issue-335609026. Azure may (or may not, depending on agent version and settings) prevent non-root users to reach the metadata endpoint for security reasons. This affects how the coreos-metadata service can be run.

Jul 03 '18 09:07 lucab

Additional cloud-specific quirk for OpenStack, coming from https://github.com/openshift/machine-config-operator/pull/964#issuecomment-511109721.

As Openstack is not an homogeneous platform and the metadata component is only optional, the static Ignition platform ID is not useful there (i.e. it can't signal whether the metadata endpoint exists or not). Thus, there is a more specific openstack-metadata provider ID for that, which is usually not baked into images kernel arguments (but can be opted-in manually). For the same reason, [email protected] does not automatically work on OpenStack, but requires a custom drop-in setting ${AFTERBURN_OPT_PROVIDER} and ConditionKernelCommandLine.

Sep 03 '19 13:09 lucab

This falls into a similar situation => https://github.com/coreos/afterburn/issues/138

Jan 12 '23 17:01 prestist

The OpenStack one is no longer relevant since #462, though CloudStack has similar behavior (#856).

Jan 12 '23 23:01 bgilbert