Hacker News new | ask | show | jobs
by dan_quixote 2124 days ago
I can assure you that OpenShift doesn't take this path because it is "better". It does so because bare-metal is a significant part of their market and there isn't a better option to automate the process currently.

I once worked on a competing product (before the OS update operator was available) and the update-in-place model was always a disaster. Various problems like dns, service discovery, timeouts, breaking changes to dependency pkgs, etc make for a problematic process. Combine that with the frantic pace of k8s develeopment, short node compatibility window (2-3 minor k8s releases) and various CVEs - you end up debugging a lot of machines in unknown states that fail to rejoin clusters after reboots.
2 comments
spicyusername 2124 days ago
This has definitely not been my experience running many hundreds of Red Hat CoreOS nodes in production.

So far, aside from a few small flakey issues, having the cluster nodes _and_ the OpenShift cluster update in lock step has been dramatically simpler to manage.

link
wmf 2124 days ago
Was that with a 1990s mutable package-based distro by any chance?
link