config: add rhcos 0.1.0 and 0.2.0-experimental variants

[bgilbert]

Add an rhcos variant with version 0.1.0 as an alias for fcos 1.3.0, and an 0.2.0-experimental spec as an alias for fcos 1.4.0-experimental. Specialize spec docs to handle each variant/version pair independently.

The idea behind 0.1.0 is to get this spec released in a usable form and gain some experience with RHCOS users using it. We might then want to add RHCOS-specific validation, which would further restrict the set of valid configs and thus be a breaking change. That development would eventually be stabilized as a 1.0.0 spec.

[arithx]

Last commit makes sense to me.

Is the plan to stabilize both fcos-1.3.0 & rhcos-0.1.0 at the same time? It'd feel weird if we had a stabilized spec that was inheriting an experimental. Not necessarily for this PR but it'd also be good if we added a set of guidelines in the development docs for what to do about specs that are inheriting non-base specs.

[bgilbert]

When we add OpenShift-specific sugar and validations, it may make more sense to call the variant openshift rather than rhcos to be inclusive of OKD. I don't think that affects the current PR, since the plan is to have a major version bump once the sugar is added.

cc @LorbusChris

[LorbusChris]

That's an interesting point.
For me the question here is really: Where are these varianted CoreOS Configs going to be used?

If it's within MachineConfig objects (openshift/machine-config-operator#1980), I think calling the variant openshift makes a lot of sense to reflect that is has to be supported by the MCO, as that's the operator that manages and applies it (no Ignition involved)

If the config were meant for first-provisioning of RHCOS machines with Ignition on the other hand, it would make more sense to call the variant rhcos to reflect the specificities of the underlying OS, but I don't think that's really a supported use-case.

[bgilbert]

We have an internal work item to discuss how to better integrate FCCs with MachineConfigs. But in addition, we'll have users using FCCs to generate Ignition configs for inclusion in a UPI pointer config, for example for root disk RAID. In that case it doesn't make sense for users to specify fcos, but as mentioned, OKD users may want to use rhcos-specific sugar once that sugar exists.

[bgilbert]

Lifting WIP.

[bgilbert]

Rendered docs site is here.

[jlebon]

Nice! Well laid out commits.

[bgilbert]

Note that this will break existing links to individual spec docs (but not to the specs index page).