distro: add rhcos

[arithx]

This adds an RHCOS variant. It is currently a no-op and just allows the
usage of the variant name in the configuration.

NOTE: Current versions of RHCOS are still based on Ignition spec 2.x
configs and will not be able to use the configs output by FCCT.

[darkmuggle]

Excellent.
/approve

Merge at will.

[LorbusChris]

/cc @crawford

[crawford]

Current versions of RHCOS are still based on Ignition spec 2.x configs and will not be able to use the configs output by FCCT.

What is the purpose of this change?

[bgilbert]

I don't think this makes sense right now. RHCOS can't currently consume the output of this tool, and by the time it can, there won't be any point in exposing FCOS spec 1.0.0 as RHCOS spec 1.0.0. Any reason not to defer this?

[arithx]

What is the purpose of this change?

We're starting work on complex devices and plan to use FCCT as an easy point for designating custom root filesystems / LUKS devices.

Any reason not to defer this?

I'm fine with deferring, cc @darkmuggle

[ashcrow]

Is this still something we want to pursue?

[LorbusChris]

openshift/machine-config-operator#1678 is somewhat related as that changes the CL configs in the MCO templates to Fedora CoreOS configs (they'll be transpiled to spec v3. and then translated down to spec v2 for OCP).
I don't see a reason why we'd have to create an RHCOS config variant though if we can just use the standard Fedora one

Edit: Note though that for the MCO templates no variant is specified and we just call the translator function directly, not via getTranslator()

[arithx]

I don't see a reason why we'd have to create an RHCOS config variant though if we can just use the standard Fedora one

My main thoughts are:

1. It's not the most intuitive to specify FCOS as your distribution even when generating a config for RHCOS
2. In the future there's likely to be additional distro specific bits that only would apply to RHCOS that we would want to add sugar for

[LorbusChris]

While I don't think it's desirable to add any distro-specific sugar unless absolutely necessary, I do agree that having an RHCOS variant would be more ergonomic for OCP users (even if it's just an alias -- i.e. what this PR does)

[cgwalters]

RHCOS can't currently consume the output of this tool,

It can now that 4.6 is on spec3!

and by the time it can, there won't be any point in exposing FCOS spec 1.0.0 as RHCOS spec 1.0.0.

I don't think this is so much about the spec as the ergnomics of the tool - support for generating configs from inline data as well as the filesystem.

[cgwalters]

Now, we clearly need a longer term storm for what the spec means here. But everything that's in 1.0.0 of the fcos spec applies to rhcos right?

[cgwalters]

The reason I'm reviving this issue is in order to improve the RHCOS static IP addressing story I think we basically need:

$ mkdir -p master0/etc/NetworkManager.conf.d/
$ cat << EOF >master0/etc/NetworkManager.conf.d/staticip.conf
...
EOF
$ openshift-install --dir=inst/ create ignition-configs
$ cp inst/master.ign master0.ign
$ openshift-install ignition-extend ./master0.ign master0/

Where ignition-extend would be the equivalent of fcct -d master0 -o master0-static.ign then merging master0-static.ign as an inline include in master0.ign.

[arithx]

Now, we clearly need a longer term storm for what the spec means here. But everything that's in 1.0.0 of the fcos spec applies to rhcos right?

All of the versioning number stuff is currently relatively confusing. The 1.0.0 is mostly pointing at the base/ version and would be consuming the rhcos_0_1 sugar (note: in the current PR it's actually using the fcos sugar as I noticed that I had made an incorrect assumption a week or two ago).

I still have this PR on my radar, I'm tossing around a couple different ideas to clean up the public API (#115) to attempt at making things a bit more clear and provide a better way to call into the distro sugar + base combination of TranslateBytes.

[crawford]

@cgwalters regarding #79 (comment), can you write up the UX in an enhancement? I have a slightly different approach in mind.

[bgilbert]

Obsoleted by #164.