[usr1106]

Yes, sorry, unprecise terminology. When I say CoreOS I mean CoreOS Container Linux.

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.

[jhart99]

From what I've seen so far, it is a continuation in name only. Many of the things that made CoreOS nice have disappeared like locksmith, and other stuff has been made incompatible for no good reason, for example dropping docker...

[cmurf]

Fedora has preferred podman for a while, it's not unique to Fedora CoreOS. Much of that has to do with Docker's choices.

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...

[kaeso]

> have disappeared like locksmith

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

[2] https://github.com/coreos/zincati

[3] https://github.com/coreos/rpm-ostree

[the_why_of_y]

Last I heard Docker still doesn't support cgroups-v2, 4 years after it was merged into Linux.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[yebyen]

This is generally one of the philosophical differences I see between the RHAT family of distributions and some others (those that I personally favor), that seamless upgrades are generally not well supported from each major version to next.

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.

[1]: https://access.redhat.com/solutions/637583

[emmelaich]

I've upgraded multiple Fedora machines from Fedora 19 up to the current Fedora 30 without too much issue.

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.

[d0ugal]

I’m the same. I never upgrade cattle, they get replaced and only pets are upgraded.

[yebyen]

I will concede, Fedora has as good a reputation and it's what I run on my desktop at home! Good point.

[dralley]

Honestly I've had more success migrating between versions of the Fedora family than the Ubuntu family. I don't have enough experience with Debian to judge.

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.

[hoistbypetard]

> In an case I disagree totally with the assertion that Fedora isn't good at upgrades between versions.

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.

[yebyen]

I said RHAT family, but honestly I did not mean to include Fedora. I've been upgrading my Fedora Core desktop since probably 26, it's not the machine that gets the most use, but it works at least as well through upgrades as the Ubuntu and Debian systems that I maintain.

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.)

[yebyen]

I'm not sure that migrating to systemd is as hard as you think, I've done it on my Debian release train, and I've also done it with Ubuntu, after migrating from Sys-V to Upstart, no less even...

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.

[vetinari]

They are, but there are some requirements to be fulfilled.

For 7.6 -> 8, see https://access.redhat.com/documentation/en-us/red_hat_enterp....

[yebyen]

Thank you! I assume there are requirements to fulfill for the other distros which support it as well but they are probably not as well documented.

One thing which RedHat has always impressed me with is the quality of their documentation.

[pnutjam]

I've been upgrading the same Opensuse installation since 11.1, and I've moved it to 2 new machines without re-installing...

If we're bragging...

[marcinzm]

>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.

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.

[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.

[deogeo]

> but if everything goes without "surprises" in real life, I would be surprised.

Do you also shave all those, and those only, who do not shave themselves?