11:23 <telmich_> good day

12:42 <tardyp> telmich_: hi!

12:45 <telmich_> tardyp: I'm currently checking out buildbot to automate helm chart generation in our infra. I first checked out jenkins, but seeing it consume 4GB ram right away is a bit of a shock. I actually did not hear about buildbot until starting to research last week

12:45 <telmich_> ... but it looks quite promising and slim!

12:47 <tardyp> indeed, buildbot is slim and simple

12:47 <tardyp> maybe for kubernetes CI/CD, you want to use tools more specialised for "cloud native"

12:47 <telmich_> I was thinking about that, too

12:47 <telmich_> But I did not find anything that fit me right away

12:48 <telmich_> As far as I can see, buildbot uses "static" workers - I first was thinking that does not really fit, but then again, this is more a resource question rather than a scheduling question

12:48 <tardyp> https://www.gocd.org/kubernetes/

12:48 <tardyp> buildbot can use dynamic works

12:48 <tardyp> workers

12:49 <tardyp> those are called latent worker in our sematics

12:49 <telmich_> Interesting. And you are very funny, pointing to gocd as a starter when joining the buildbot room - I like the attitude :-)

12:52 <tardyp> actually argocd is the tool that my kube fellow use https://argoproj.github.io/argo-cd/

12:53 <tardyp> but indeed, buildbot is more a generic framework and can't really keep up with very fast moving cloud native movement

12:53 <tardyp> so it is more made for people who can't use the more opinionated tools like gocd/argocd

12:54 <telmich_> I had a look at argocd and was a bit overwhelmed. For CD I was more going the direction of fluxv2, but even that does not "really" do the job

12:54 <telmich_> The main problem in the k8s world is that a lot of problems are trying to be solved and often they are not solved correctly - like removing CRDs from a rook deployment, which leaves stale resources behind

12:56 <tardyp> I agree that the problem is not yet fully solved

12:57 <tardyp> helm is imho too much complicated, we rewrote all our .yml to helm, and 6 month later rewrote it again in kustomize..

12:59 <telmich_> Interesting

12:59 <tardyp> helm has too much indirection to me, it makes things too complicated for private stuff

12:59 <telmich_> I found kustomize too limited

12:59 <telmich_> Because it cannot use templates; the main problem is when you have many apps of the same type (let's say nextcloud instances) and you want to share names, like a PVC or a secret in various parts of the definition

13:00 <telmich_> In helm, you use something on the line of {{ .Values.Something }}, in kustomize the patch is rather tricky/ugly in my opinion

13:01 <tardyp> well, we just needed templating to configure the difference between dev/staging/prod

13:01 <telmich_> Also what I miss in kustomize: generating a configmap from the filenames of a directory

13:01 <telmich_> That's nice and I think that easily works

13:02 <telmich_> These two I found very hard to solve in kustomize: https://code.ungleich.ch/ungleich-public/ungleich-k8s/-/tree/master/apps/gitea and https://code.ungleich.ch/ungleich-public/ungleich-k8s/-/tree/master/apps/knotdns (the latter even impossible)

14:57 <vilhalmer> just want to say thanks for buildbot, it took a problem that we put off solving for five years and made it into a three week fix :)