Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Brief Goodbye to CentOS

clementchiew.me

Post reply on HN
Print view View original

71–80 of 163 posts

Re: A Brief Goodbye to CentOS

#71

Post by arpa »

NDizzle wrote: post #49
q3k wrote: post #41

Earlier quoted context omitted.

(you have to wait until you can reply after a certain depth - this is HN's anti-flamewar system kicking in) I understand you can restore from backups, but this doesn't seem simple to me - especially when you deal with situations where there's more than just one person deploying to production. In comparison, my rollbacks are performed the same way rollouts/rollforwards are - by editing a single line in Git (ie. changi…

I look at it this way. I think it's simpler to do this kind of backup in case things go wrong (which, honestly, is not that often. Twice in 5 years that I can think of off the top of my head) than it is to set up kubernetes, manage kubernetes, and convert our applications to work correctly in kubernetes. All of that is required so that your single line edit becomes a possibility. That's a lot of work to enable that w…

Whatever works for you, man. I honestly enjoy having docker images instead of zips and bash scripts, but I see where you're coming from.

Re: A Brief Goodbye to CentOS

#72

Post by viccuad »

pelasaco wrote: post #66
viccuad wrote: post #43

Earlier quoted context omitted.

Debian Unstable -> Testing -> Stable -> Oldstable -> Oldstable with LTS Fedora -> Centos Stream -> RHEL -> RHEL with LTS Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.

> Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Almost right :) Leap is the fixed point release, based on SLE. SLE is rebased on Tumbleweed every 3-4 years.

Well, my intent was to roughly chart the supported timeframe and expectations of each, not the flow of code through them. That SLE gets rebased from Tumbleweed directly every 3-4 years justs showcases my second point from before: SLE bumps major versions of packages between minor SLE versions.

Re: A Brief Goodbye to CentOS

#73

Post by javajosh »

NDizzle wrote: post #63
peterangular wrote: post #44

Earlier quoted context omitted.

When I was working in a stack like this I found people spending outstanding amounts of time not actually working to improve the stability/performance of the application. The reason you triggered that memory was "GKE, Prometheus, Sysdig, Grafana, ELK" - that's exactly what we were dealing with. The support infrastructure/compute needs for it far exceeded the 20-30 hosts that actually needed to be there to operate the…

"outside of a couple bitter/broken ops guys who didn't deserve what the team had done to them" Hey, that's me.

Well, if its any consolation, programmers aren't safe either. In fact, we are highly paid obnoxious people (to execs) and just imagine being able to replace one of us with a box that works 24 hours, 7 days a week for the cost of the hardware, electricity, and network. How exciting! If and when that happens, I suppose I can find work as a (bad) carpenter or something.

Re: A Brief Goodbye to CentOS

#74

Post by pelasaco »

pferde wrote: post #62
viccuad wrote: post #43

Earlier quoted context omitted.

Debian Unstable -> Testing -> Stable -> Oldstable -> Oldstable with LTS Fedora -> Centos Stream -> RHEL -> RHEL with LTS Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.

It is untrue that SLES does not support upgrades between major versions: https://documentation.suse.com/sles/15-SP2/single-html/SLES-... It is, however, true that SLES is less conservative than e.g. RHEL when it comes to bumping software versions between their minor releases (service packs). I remember that they switched from 2.6 to 3.0 kernels sometimes in SLES10 days. Fun stuff.

openSUSE however doesn't support it https://en.opensuse.org/SDB:System_upgrade#Supported_scenari...

Re: A Brief Goodbye to CentOS

#75

Post by peterangular »

cactus2093 wrote: post #60
peterangular wrote: post #44

Earlier quoted context omitted.

When I was working in a stack like this I found people spending outstanding amounts of time not actually working to improve the stability/performance of the application. The reason you triggered that memory was "GKE, Prometheus, Sysdig, Grafana, ELK" - that's exactly what we were dealing with. The support infrastructure/compute needs for it far exceeded the 20-30 hosts that actually needed to be there to operate the…

GKE is the container/kubernetes engine, but then you also mention Prometheus, Sysdig, Grafana, ELK. Sounds like much of the problem was the monitoring stack, just curious why you blame that on containers and k8s? Wouldn't you still have needed a solution for that for 20-30 hosts regardless of how you're orchestrating/running the applications?

> just curious why you blame that on containers and k8s?

Crawl, walk, run sorta stuff. We had never just gotten the application/monitoring/everything humming on pure Linux hosts skipping that entirely because "K8s and containers!" When you haven't properly QA'd, vetted, whatever your stack throwing heavy abstraction at it (containers/K8s) is an anti-pattern.

Most companies don't have the resources to run a competent K8s distributed compute infrastructure and as a hiring manager (as much as an IC) I know I have to hire very specific, very expensive people for that role. Good ops folks come with experience in their realm and the newer the tech stack the harder it is to find competent help due to talent market conditions.

I don't blame containers and K8s - I blame the people, and I blame companies/teams for jumping at new tech that often doesn't have a justifiable use-case outside of "we're doing the popular thing!" vs. really considering what the needs of the solution are.

I also have a very low tolerance for downtime, and with those huge abstractions I find stuff gets missed more often, leading to my application being down for my users. I am a KISS engineer.

Re: A Brief Goodbye to CentOS

#76

Post by twic »

fractal618 wrote: post #64

No mention of Fedora? Is it not feasible that those currently using CentOS, and don't wish to use the supported Red Hat, will gradually migrate to the CoreOS, IoT or Server version of Fedora? I would think that would be easier than migrating to a different package management system.

People use CentOS because it's stable - you can run one version for years, and get security and bug fixes, with no feature changes.

This change to CentOS means it won't have that stability, so some will need alternatives.

Fedora changes even faster than the new CentOS - a new version every six months! Each version is maintained for just over a year, and the maintenance includes new features.

Re: A Brief Goodbye to CentOS

#77

Post by phkahler »

q3k wrote: post #4
chmod775 wrote: post #2

Call me old fashioned, but I ship both my private projects and those at work as debian packages. Debian packages are trivial to put into a container, and we tried that, but honestly it's not half as nice to work with. With containers you have to do a ton of extra steps to get functionality and debugging on a level a default debian system provides you. Additionally the tools to automate the installation and configurat…

How do you handle multiple versions of the same project/software/deployment on the same machine?

Why would you want to do that?

Re: A Brief Goodbye to CentOS

#79

Post by chmod775 »

q3k wrote: post #4
chmod775 wrote: post #2

Call me old fashioned, but I ship both my private projects and those at work as debian packages. Debian packages are trivial to put into a container, and we tried that, but honestly it's not half as nice to work with. With containers you have to do a ton of extra steps to get functionality and debugging on a level a default debian system provides you. Additionally the tools to automate the installation and configurat…

How do you handle multiple versions of the same project/software/deployment on the same machine?

I never had the need to do that and I'm not sure in what kind of situation I would.

For updates I just install the new version of the software, then perform a restart (new version starts, once it's ready, old version stops).

Re: A Brief Goodbye to CentOS

#80

Post by dsr_ »

peterangular wrote: post #28
chmod775 wrote: post #2

Call me old fashioned, but I ship both my private projects and those at work as debian packages. Debian packages are trivial to put into a container, and we tried that, but honestly it's not half as nice to work with. With containers you have to do a ton of extra steps to get functionality and debugging on a level a default debian system provides you. Additionally the tools to automate the installation and configurat…

I'm really considering doing this for a new spin-up myself... The stability of Debian tooling for large-scale, hyper scaleable solutions is outstanding. I just feel like the world balks at me every time I do something considered slightly "old fashioned" completely ignoring the finished product to shame me for not using buzz-word tooling. Containerization is fantastic don't get me wrong, but I've had more success with…

Debian plus an automation system like Puppet, Chef, etc works extremely well.

It's just not sexy enough for people to write hundreds of posts about how to set up your own package repo, understand unattended-upgrades, and do monitoring.

Post reply on HN