[06:21:27] <hashar>	 dduvall: from what I understand the merger is part of the executor by default which simplify the arch by having one less component and if needed the mergers can be scaled horizontally independently from the executor
[06:21:56] <hashar>	 jelto: would it help if I write down somewhere an history of how we deployed Zuul?
[06:22:02] <hashar>	 aka debian packaging > 
[06:22:40] <hashar>	 aka debian packaging   >> a Makefile  with `docker run python2-build`
[06:25:21] <hashar>	 and the different paths we can use?  Ideas I have so far:
[06:25:21] <hashar>	 a) use upstream images much like we don't rebuild Jenkins or Gerrit war
[06:25:21] <hashar>	 b) build our own with blubber/Poetry
[06:25:21] <hashar>	 c) have our new Zuul to build the images for itself (how what where: no clue)
[06:28:08] <hashar>	 ---
[06:29:26] <hashar>	 and looking at the zuul kubernetes operator, the executor (https://opendev.org/zuul/zuul-operator/src/commit/1c627c53c525fc4890e88be1c108808cbe448deb/zuul_operator/templates/zuul.yaml#L282-L284 ) is marked with privileged: true (  https://opendev.org/zuul/zuul-operator/src/commit/1c627c53c525fc4890e88be1c108808cbe448deb/zuul_operator/templates/zuul.yaml#L340-L341 )
[06:30:00] <hashar>	 which leads me to wonder whether we could deploy the Zuul controlling plane on Kubernetes using that operator