How to take down production with a single Helm command
1–10 of 18 posts
Re: How to take down production with a single Helm command
#2Tangentially related, cannot help but be reminded of the "Ohnosecond": https://en.wikipedia.org/wiki/List_of_humorous_units_of_meas...
Re: How to take down production with a single Helm command
#3Explanation here: https://github.com/helm/helm/issues/12681#issuecomment-19593...
Looks like it's a bug in Helm, but actually isn't Helm's fault, the issue was introduced by Fedora Linux.
(This issue is linked from the article, but it took me some time to find it.)
Re: How to take down production with a single Helm command
#4Explanation here: https://github.com/helm/helm/issues/12681#issuecomment-19593... Looks like it's a bug in Helm, but actually isn't Helm's fault, the issue was introduced by Fedora Linux. (This issue is linked from the article, but it took me some time to find it.)
why would someone use Fedora in production, tho ?
Re: How to take down production with a single Helm command
#5I've seen enough of these over the last two decades, between Ubuntu/Debian and RedHat, that I use and inherently trust other distros more. Just compile the source packages. If there is some issue, file a bug. Monkey patching everything silently leads to things like this, which I've never experienced with distros like Arch, Void, or Solus.
Re: How to take down production with a single Helm command
#6Explanation here: https://github.com/helm/helm/issues/12681#issuecomment-19593... Looks like it's a bug in Helm, but actually isn't Helm's fault, the issue was introduced by Fedora Linux. (This issue is linked from the article, but it took me some time to find it.)
why would someone use Fedora in production, tho ?
helm runs on the operator machine, not server. While fedora server might not be very popular, fedora workstation seems to be pretty popular.
Re: How to take down production with a single Helm command
#7I've seen enough of these over the last two decades, between Ubuntu/Debian and RedHat, that I use and inherently trust other distros more. Just compile the source packages. If there is some issue, file a bug. Monkey patching everything silently leads to things like this, which I've never experienced with distros like Arch, Void, or Solus.
For helm and most other golang apps, you just need to download and put binary into your $PATH. They usually put them onto github releases, so it's really low friction way to install a genuine application.
Now to keep them updated is another story.
Re: How to take down production with a single Helm command
#8I've seen enough of these over the last two decades, between Ubuntu/Debian and RedHat, that I use and inherently trust other distros more. Just compile the source packages. If there is some issue, file a bug. Monkey patching everything silently leads to things like this, which I've never experienced with distros like Arch, Void, or Solus.
For helm and most other golang apps, you just need to download and put binary into your $PATH. They usually put them onto github releases, so it's really low friction way to install a genuine application. Now to keep them updated is another story.
Last sentence. I love Go's install and run story, but keeping it up to date is a pain.
We trust, or used to trust, distros for this. Why are they messing with the source?
Re: How to take down production with a single Helm command
#9> Apparently the version of Helm packaged in Fedora Linux included a patch that introduced this issue
Let's translate: how to take down whatever by living on the bleeding edge.
Re: How to take down production with a single Helm command
#10Earlier quoted context omitted.
For helm and most other golang apps, you just need to download and put binary into your $PATH. They usually put them onto github releases, so it's really low friction way to install a genuine application. Now to keep them updated is another story.
Last sentence. I love Go's install and run story, but keeping it up to date is a pain. We trust, or used to trust, distros for this. Why are they messing with the source?
My understanding is that they've more or less always done this for various reasons: security patches, compatibility, dependency versioning.
I understand the historical reasons that led to this structure for package management, especially with how brittle C dependencies seem to be, but I truly hate this practice. It seems to make it exceptionally difficult for authors of major software to establish any sort of invariants or security boundaries.