[slrz]

> upgrades from eg CentOS 6 to 7 are unsupported.

Upgrades from EL7 to EL8 are supported, though.

For Container Linux/Fedora CoreOS, in-place updates don't make much sense. Those are intended as immutable OS images. They get their configuration from a remote source specified on the kernel command line.

The migration work is dealing with changes in the configuration language.

[mroche]

Upgrades between CentOS are not officially supported. Upgrades from RHEL 6 -> 7 and 7 -> 8 are supported, but only for an extremely small subset of packages and systems setups. It’s not really worth it. PXE boot with custom kickstart and post config (e.g. Ansible) runs are a much better solution than the in place upgrades.

[usr1106]

> The migration work is dealing with changes in the configuration language.

Yes, that's how all installations work for CoreOS Container Linux. The problem is the day when the autoupdate of the current distro stops (no more new images, and that's supposed to happen soonish, although no date has been communicated) your old configuration language will stop to work (unless you are happy enough not to used anything on the list of incompatibilities, which is pretty unlikely for non-trivial installations). And then you need to port and test.

In my experience coding the configuration takes at least 3 times as long as installing in a traditional way. That is a worthwile investment if you want to be sure what you have installed and want to be able to start identical machines later. But if the investment is broken by commercial/political decisions that's frustrating.

Well, I am not a paying customer, so I cannot really complain. I just have to decide whether I am happy with the flatcar fork or whether I port my configuration to Fedora CoreOS. At the moment they have no complete documentation AFAIK, So it's difficult to make a decision.

[blixtra]

We started Flatcar Container Linux to provide the option of continuing as is. We don't like to see perfectly good software be discarded simply because of an acquisition. We understand the hassle with porting configurations and have found a good number of organizations who are supporting our effort through support contracts to continue in the manner they intended when they chose to use CoreOS Container Linux.

We also released the update service as an open source project, Nebraska (https://github.com/kinvolk/nebraska). That was something that was closed source with CoreOS. This allows you to be in control of your updates.