Are you thinking of Container Linux by CoreOS (The company purchased by Red Hat)? Fedora CoreOS is a continuation of Container Linux.
See https://en.wikipedia.org/wiki/Container_Linux#Derivatives
See https://en.wikipedia.org/wiki/Container_Linux#Derivatives
Fedora CoreOS is marketed to be a continuation. But it's not a seamless one, it requires manual porting. Detailed instructions don't exist yet, but the list is not that short https://github.com/coreos/fedora-coreos-tracker/issues/159. While most people won't be affected by many items, a couple of days are easily burned for understanding, coding and testing. Coding probably the smallest part, but if everything goes without "surprises" in real life, I would be surprised.
For example, and I'm sure I'm oversimplifying, and there are caveats; for years, I've maintained Debian and Ubuntu machines which I've used mostly staying inside of the bounds of the apt package manager, and since many years I've never had a need to question whether I could "dist-upgrade" from one release to the next. It just works.
It is a supported operation, and reliably so. At my current job, we use Amazon Linux, a distro which I understand to be mostly derived from CentOS with Amazon addons, (and I'm open to being corrected if anybody knows better, but...) one of the things we're coping with right now is that Amazon Linux 2 does not have an upgrade path from Amazon Linux 1. We are on the hook to rebuild those machines, it's a fact that has given us pause to seriously re-evaluate whether we want to stay on the same train, or get off and switch to another paradigm broadly.
I don't strongly see this as a decision that Amazon made, because I'm fairly sure it's also true that upgrades from eg CentOS 6 to 7 are unsupported. And CentOS apparently got this idea from RedHat Enterprise Linux upstream, which provides this helpful page locked behind paywall[1], but from above the fold you can tell at least one thing without logging in: there are only a limited set of cases where upgrades are supported, even with a paid subscription to RHEL.
Contrariwise, I've found various issues with Debian and Ubuntu.
That said, I rarely do dist upgrades of prod systems at all; I install the base os from scratch (pxeboot etc) and use automation to install the rest.
In an case I disagree totally with the assertion that Fedora isn't good at upgrades between versions.
CentOS 7 upgrade would be tricky to do automatically because of the systemd transition and the fact that any Enterprise user would likely have a ton of services they need to migrate safely.
Same here. I think that changed somewhere around Fedora 15, though. Prior to that it was a minefield. That's probably why it has such a bad reputation among those who've not tried recently.
My current desktop workstation started out at Fedora 14 and now sits at 31. It's gone through multiple motherboard and component upgrades over that time, too.
But none of my servers run Fedora. I still think that the core use case for Linux is servers. (And that's not to say my servers couldn't run Fedora... but it so happens the OS distribution that we use at my $dayjob is usually Centos or Amazon, sometimes RHEL, occasionally Ubuntu, but for some reason absolutely never Fedora.)
It's actually standard policy from what I understand on the distros that are in the RHEL family, that upgrades between major version of releases are officially not supported.
So, Fedora is nice, but if you're using RHEL, be prepared to rebuild everything from scratch every 2-3 years, I guess?
The same is true for Amazon Linux -> Amazon Linux 2.
For 7.6 -> 8, see https://access.redhat.com/documentation/en-us/red_hat_enterp....
One thing which RedHat has always impressed me with is the quality of their documentation.
If we're bragging...
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.
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.
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.
That's part of the selling point of Kubernetes. Your base OS needs to have just enough to run Kubernetes so upgrading it (ie: nuke and rebuild) is easy. You containers on the other hand can be upgraded piecemeal and are built with code. It's more things to handle but makes each thing smaller in scope.
moby-engine https://koji.fedoraproject.org/koji/packageinfo?packageID=27...
docker https://koji.fedoraproject.org/koji/packageinfo?packageID=51...
podman https://koji.fedoraproject.org/koji/packageinfo?packageID=26...
Locksmith[0] implementation is tightly coupled to the specific update daemon, so it can't be directly re-used outside of Container Linux or without update-engine[1].
Its logic has been ported over to Zincati[2], which performs reboot management on top of rpm-ostree[3].
[0] https://github.com/coreos/locksmith
[1] https://github.com/coreos/update_engine
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Do you also shave all those, and those only, who do not shave themselves?