MCS: Supporting Ignition v3

[cgwalters]

Related #479

Using "I2" and "I3" for shorthand "Ignition spec v2" and "Ignition spec v3".

We need to support upgrades from 4.0 → 4.1. It feels like we need to simultaneously support I2 and I3 when booting a node. This is related to the MCS (Ignition server). A new master machine boots and the OS speaks I3. Does the MCS have both rendered v2/v3 versions and detect the client version based on e.g. User-Agent or something and serve the right one?

Or does I3 on the machine support reading I2 and translate?

It feels like a grounding assumption here is that we can reliably do this translation; there's concern about ambiguous/broken cases in I2 but let's assume we don't have those cases in our configs, or if we do we error out much earlier than the MCS (e.g. in the render controller).

[runcom]

This card is now out of scope, we should be updating the whole Ignition dependecy to v3 once it comes out and adjust the code.

[cgwalters]

Based on some discussion with bgilbert I think we need Ignition to tell us whether the host is FCOS or RHCOS too.

[cgwalters]

See also coreos/coreos-assembler#537

[cgwalters]

Also, what makes this issue complex is that we need to support booting from the 4.1.0 bootimages:
openshift/os#381

So the MCS would need to support both. Unless that issue is solved first which would be...nontrivial.

[cgwalters]

Personally on this I think we can handle translating a vast majority of what OpenShift customers are doing today. So we'd add a translator into the MCS.

[yuqi-zhang]

One thing is, even if we have updated bootimage in place, we'd run into a slight problem if we don't handle both: we'd need to simultaneously update bootimage at the point we "upgrade the cluster to spec3" in one encapsulated update (from my understanding).

[cgwalters]

The initial proposal here sketches out a way to handle both old and new bootimages via User-Agent detection in the MCS.

[cgwalters]

Hm actually I forgot today that the installer is generating the initial "pointer config" user data for AWS which is spec 2 by default too.

So one tricky part here is that updating bootimages to a point where they only speak e.g. spec3 and not spec2, we'd also need to update their user data at the same time.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale