Rename FCCT

[bgilbert]

With the addition of the rhcos variant (#164), FCCT is no longer specific to FCOS.

[LorbusChris]

I think we should do it - and along with it refer to the family of CoreOS Configs as either CC or since that term is overloaded, maybe even better something like COSC.

[bgilbert]

I was thinking we'd continue to refer to the configs by variant - so we'd have FCC, RCC, etc. Open to ideas though.

[miabbott]

How about Ignition Config Transpiler (ict)? We can avoid additional overloading coreos this way.

[bgilbert]

@miabbott Doesn't that imply that we're consuming Ignition configs rather than producing them?

In any event, we'll still need a name for the input format. I agree "CoreOS Config" isn't great, but I guess the alternative is a new arbitrary name.

[miabbott]

@miabbott Doesn't that imply that we're consuming Ignition configs rather than producing them?

In any event, we'll still need a name for the input format. I agree "CoreOS Config" isn't great, but I guess the alternative is a new arbitrary name.

I dunno...I suppose it depends on how you parse the name. I read it as "this tool produces Ignition configs". It seems either interpretation could be correct...so maybe an arbitrary name would be better.

[bgilbert]

See related discussion at kubernetes-sigs/cluster-api#4172 (comment).

[ashcrow]

Maybe we should discuss a name for the format first. If we can find a replacement for "Fedora CoreOS Config" that possibly follows the ignition theme that may help us move this forward. I'm not well versed in engine ignition stages but I'm sure the Internet can enlighten us 😄.

[Okeanos]

I have no stakes in this but would like to point out that a brew formula for this project (aptly named fcct) exists and can, in the end, hopefully be renamed without conflicts.

As an addendum: coreos-ct for the previous version of CoreOS also still exists in a deprecated state.

[LorbusChris]

@miabbott Doesn't that imply that we're consuming Ignition configs rather than producing them?

In any event, we'll still need a name for the input format. I agree "CoreOS Config" isn't great, but I guess the alternative is a new arbitrary name.

I'm +1 for Ignition Config Transpiler!

FWIW when I google "c transpiler" the very first link is to (edit: well-named) https://github.com/dbohdan/compilers-targeting-c

[bgilbert]

I think it's worth exploring along the lines of @ashcrow's comment. A rename to "ICT" doesn't address the naming of the individual distro configs, and if we eventually get more uptake with other distros, our current naming scheme probably won't work. "Debian Config" would be too generic, "Debian CoreOS Config" too confusing. Already the situation is messy enough with FCCs and RCCs and maybe "OCCs" (OpenShift CoreOS Configs?).

If we can find a new tool name X, then we could have X Configs (an umbrella term for YAML documents consumed by X; we don't have such a term right now) and maybe FCOS X Configs and OpenShift X Configs.

[travier]

I was thinking of something fuel related, as in FCCs/Configs are the fuel needed for Ignition?

[LorbusChris]

also bikeshedding a bit:

• Oxy Config (FOxy and RHOxy) (add a spark and you have ignition)
• Core Config
• Coreositizer / Coreosity

[miabbott]

I was thinking of something fuel related, as in FCCs/Configs are the fuel needed for Ignition?

How about Butane?

Reasonably passes a quick search on butane linux and butane config; only hit is a Ruby gem that was last updated about 10yrs ago

[jlebon]

How about just keeping it as "fcct" but changing what it stands for? (I joked once the letters reminded me of focaccia). Or we can pull an OKD and just say it doesn't stand for anything. 😉

[LorbusChris]

"Fairly Capable Config Transpiler" or "FCCT Compute(r) Config Transpiler"

[ashcrow]

I also like the idea of having it recursive 👍.

• "FCCT Combined Config Transpiler"
• "FCCT Compose & Config Transpiler"
• etc...

[control-d]

@miabbott Doesn't that imply that we're consuming Ignition configs rather than producing them?
In any event, we'll still need a name for the input format. I agree "CoreOS Config" isn't great, but I guess the alternative is a new arbitrary name.

I dunno...I suppose it depends on how you parse the name. I read it as "this tool produces Ignition configs". It seems either interpretation could be correct...so maybe an arbitrary name would be better.

Will that be confusing if the tool defaults (for some variants) to producing MachineConfigs instead?

I like CoreOS Config Transpiler (cct), though I can see how that might be a problem if ignition makes it's way into other distros. I imagine that Ignition Config Transpiler will make a lot of sense in those situations where ignition is standalone.

[sinnykumari]

How about:

MCT (Machine Config Transpiler)
or,
MOSCT (Machine & OS Config Transpiler)

It covers ignition configs as well any distro/product specific configs that applies to configure system.

[ashcrow]

MCT sounds good -- but it could be confusing for folks using OCP since the end result is an Ignition file rather than an OCP Machine Config. However, #212 may change that.

No matter which way we go I propose we move to a decision sooner rather than later. fcct no longer makes sense as a name and many fair ideas have been proposed (including MCT) which could be used instead.

[sinnykumari]

MCT sounds good -- but it could be confusing for folks using OCP

Yeah, that's why I also proposed MOSCT 😆

[cgwalters]

Did the idea of having this functionality embedded in oc come up? i.e. oc coreos-config or something. (Leaving fcct as-is for the FCOS and other use cases)

[cgwalters]

If we add this to oc it may make sense to roll in with openshift/oc#628

[bgilbert]

@cgwalters We've discussed vendoring FCCT into oc but we're not pursuing that at the present time. In any event, the codebase will still handle OSes beyond Fedora CoreOS, so it wouldn't save us from a renaming.

[cgwalters]

Right, but with this approach this project becomes more of a Go library - other projects would ship their own binaries.

[ashcrow]

binary || library are there any objections for us taking the proposed names and giving folks a little time to vote? I'd like us to come to a conclusion sooner rather than later if possible.

[cgwalters]

If we choose the library path there isn't any renaming, or at least not immediately; the functionality for rhcos and MachineConfigs in particular would mainly be exposed as part of oc.

[ashcrow]

If we choose the library path there isn't any renaming, or at least not immediately; the functionality for rhcos and MachineConfigs in particular would mainly be exposed as part of oc.

That is true. In that case why don't we have someone chose an option and run with it. We have some good ones and by making a choice we can close this issue out and signal the functionality isn't tied to Fedora directly.

[bgilbert]

This is on my plate in the next day or so.

[bgilbert]

I propose that we adopt Butane (suggested by @miabbott), refer to the configs as Butane configs regardless of their variant, and use the file extension .bu. If you have a strong objection, please NACK now.

Reasoning:

• We need names for both the tool and the file format. For the last couple months I've been trying to distinguish between FCCs/RCCs/OCCs in conversation and it's pretty awkward, so I believe we should switch to one overarching name for the config format. The variant should generally be clear from context anyway.
• We should avoid putting "CoreOS" in the name. Ignition is meant to be useful on non-CoreOS systems, and FCCT should be also. (The codebase already separates CoreOS-specific sugar from distro-independent sugar.)
• The name should ideally be simple, pronounceable, not already in widespread use, and have some intuitive connection to Ignition. The original "FCCT" descriptive name was a compromise, because we couldn't find an ideal name the first time either. I've spent some time looking at rocket and aviation engines, their startup processes, and rocket/aviation fuel, and didn't find any names that were really on point.

Other finalists I considered:

• Keeping "FCCT" and "FCC", but changing the notional expansions to "Fairly Capable Config [Transpiler]"
• Tool "ICT" (Ignition Config Transpiler), file format "ITC"
• "Ramjet", file format "Ramjet config" or "RMC"