Issue #4 - A universal Helm chart
Most application helm charts are a mashup of common Kubernetes artefacts like deployments, services, volumes etc. So, why not create a universal Helm chart which caters to 80% of these requirements? I elmbarked on this experiment, but did some due diligent googling to find out if people have thought of this before. Looks like I was right.
This gem I found on Github helps create a Helm installation for your application and provides deployments, volumes, statefulsets, jobs, helm hooks, secrets, configmaps, HPAs, service accounts, and even service monitors. Best part is, it works with OpenShift as well. Some YAML magic goes a long way I guess.
Under what circumstances would I write a Helm chart from scratch? Only case I can think of is when I have some specific Custom Resource, or when I am providing a set of Custom Resource Definitions.
The Terraform licensing change caused quite a stir in the industry, and lead to a fork as well. I read a thread( from here) describing what a bad joke it was to fork Terraform. To summarize, when you fork an open source project, you are just doing a fork of the code base. A lot of other not-so-obvious things are not thought through. Like community, RFCs, enterprise vendors support, engineering effort in triaging bugs, PRs etc. We have to respect the fact that a lot of man hours have gone into developing Terraform into what it is today.
Parkinson’s law, simply put, states that work always expands the time available to do it. I watched a video about reverse Parkinson’s law.
The TLDR; is, if you compress the amount of hours you’re going to work on a given day and religiously stick to it, you will achieve the same throughput and will also be left with more time for the rest of the day. Essentially a flipped version of Parkinson’s law.
If work expands the time available to fill it, then allot substantially lesser time for that work.
I’ll buy that.