Helm

People often ask me “how do I make my first PR?”, the answer is simple — just do it. But I want to write a series of notes about open source culture and how to make life convenient for everyone. Today we’ll look at a case I encountered yesterday, namely — multiple changes to one semi-abandoned repo. TL;DR When preparing a large refactor in an open source project: Break into small logical PRs — reduces cognitive load on reviewers Propose integration branch for coordination — allows incremental review and batch changes If in doubt, don’t hesitate to reach out to the team early — openness and communication matter Be ready for iterations — open source is about people This reduces load on reviewers and increases chances of successful merge. ...

VIP for Kubernetes API Alright, time to brag a bit: I became completely disillusioned with solutions like metallb, cilium, kube-vip, etc. for announcing kube API. Also, I don’t want to do this externally. I don’t want to manage it on hosts. I don’t want to manage peer lists. Therefore, vipalived. (Won the naming contest; “lube-vip” came in second). A bit of context: Cilium replaced my kube-proxy, metallb, ingress controller, and CNI. It’s cool and optimal — previously there were several network tools, now just one. But there’s a side effect: Cilium became critically dependent on the kube API. This makes it unsuitable for VIP of the kube API itself — a vicious cycle. ...