Comment by xorcist
7 years ago
> The one thing you never really do, as an ops person, is reach into the black-box components
I'm sorry, but just no. That's far too strong general statement. I've done quite a bit of sysadmin/devops style work over the years, and also worked with many other people who've sent various kinds of fixes upstream. Sure, third party software isn't always easy to fix, but it depends on what the alternatives are. You probably need to do an immediate workaround as well.
I would say that's an important part of why open source have had such a strong following among sysadmins, the ability to fix things. One could even say that diving into large pieces of software and exploring issues is the most rewarding part of the job. Just don't tell them I said that.
Usually I've ventured into the code and made a bad enough attempt to fix that the devs are galvanised into doing it right. Filing a ticket usually not enough table stakes to get your voice heard if things are worked around.
I like this concept. I wonder if there’s a word for it. Any Germans want to help out with a fifteen syllable wonder?
Tikettfileninsufficientstadtdelvencodebasefixen.
Or something? More seriously, relevant English idioms:
- A stitch in time saves nine;
- Something worth doing's worth doing well;
- If you want it done right, do it yourself;
and surely more. I'm certain there's a farming-analogy one about fixing something sooner rather than later, but it's escaped me.
2 replies →
Threat-in-a-patch
Duct tape ops?
Agreed.
I found that the best way to get reliable ops long-term is to mercilessly dive into the code for every issue encountered, and fix it at fundamental level.
It takes significant time, but after following this practice for a while, things start working reliably.
I'm currently doing this with software like GlusterFS, Ceph, Tinc, Consul, Stolon, nixpkgs, and a few others.
In other words, try to make it so that none of your components is a black box to you. Own the entire stack, and be able to fix it. That makes reliable systems.
> Agreed.
> I found that the best way to get reliable ops long-term is to mercilessly dive into the code for every issue encountered, and fix it at fundamental level.
> It takes significant time, but after following this practice for a while, things start working reliably.
> I'm currently doing this with software like GlusterFS, Ceph, Tinc, Consul, Stolon, nixpkgs, and a few others.
> In other words, try to make it so that none of your components is a black box to you. Own the entire stack, and be able to fix it. That makes reliable systems.
Do you then submit your fixes back to upstream? This is the critical element I think.
Do you then submit your fixes back to upstream? This is the critical element I think.
It makes sense to, otherwise you're stuck forward-porting your private patches forever. Or worse, get stranded on an old version because there's no-one around who can do that forward-porting anymore...