[04:52:35] <marostegui>	 I am switching over phabricator db master in a few minutes
[10:47:21] <vgutierrez>	 somebody has it handy the CLI to run locally the CI tests for our puppet repo inside the docker container?
[10:47:31] <vgutierrez>	 >3minutes per test to check a lua script it's a nightmare
[10:48:02] <vgutierrez>	 but it won't work outside a container cause bullseye lua version
[10:48:04] <volans>	 vgutierrez: isn't in utils?
[10:48:19] <vgutierrez>	 oh, /run_ci_locally.sh
[10:48:25] <vgutierrez>	 damn brain
[13:33:16] <klausman>	 Hmmm. I am using the k8s node reboot cookbook, with a batch size of 3, and it didi two nodes, and when they were done, it cordoned the remaining six machines. Did I use -b wrong?
[13:34:21] <klausman>	 https://phabricator.wikimedia.org/P33717
[13:35:21] <volans>	 jayme might enlight you
[13:35:25] <klausman>	 cmdline was cookbook sre.k8s.reboot-nodes --batchsize 3 --reason "Reboot to pick up kernel 5.10.136 (T316185)" -a ml-serve-worker-codfw reboot
[13:37:04] <klausman>	 Hmmm. might be an attempt to avoid drained hosts sending pods to other hosts that will be drained next (cordoned !=drained). But I still wonder why it started with only two
[13:37:29] <volans>	 (in the sense that he might shed some light as he's the expert for that cookbook ;) )
[13:37:38] <klausman>	 Ack. :)
[13:37:52] <klausman>	 It's not breaking anything, but it's a bit surprising
[13:42:27] <jayme>	 klausman: regarding the cordoning you are right. The cookbook does so to avoid evicted pods to be scheduled on soon-to-be-rebooted nodes
[13:43:40] <jayme>	 it also tries to be smart about the batch size, making sure it's not more than 20% of the hosts in one "group"
[13:44:07] <jayme>	 where a cluster can consist of multiple groups, depending on the node taints
[13:44:12] <klausman>	 SO with eight nodes that is 1.6, rounded to 2, I suspect
[13:45:17] <jayme>	 exactly
[13:46:12] <jayme>	 it should have said so, though
[13:46:20] <jayme>	 "Using reduced batchsize of %s due to small host group (%s hosts)"
[13:46:34] <klausman>	 yeah, I totally missed that
[13:46:51] <jayme>	 very easy to miss things in all that output :)
[13:51:13] <klausman>	 there is a special kind of TMI in tools like these :D
[13:52:41] <jayme>	 very happy it worked for ml as well :)
[13:53:39] <klausman>	 Same!
[13:53:43] <klausman>	 Thanks for making it
[14:39:58] <andrewbogott>	 apergos: if you have a change to look, I'm interested in your opinion about whether the new dumps servers are 'ready'.  All I can really tell at this point is they seem to be doing all the things that puppet is telling them to do.
[14:42:47] <apergos>	 andrewbogott: ok, I'll take a look either this evening or tomorrow day
[14:42:55] <andrewbogott>	 thanks!
[15:00:08] <_joe_>	 moritzm: did you upgrade php 7.4 everywhere already?
[15:52:32] <moritzm>	 _joe_: no, I didn't update anything?
[15:52:50] <_joe_>	 uhhh
[15:53:09] <_joe_>	 why do we have buster3.1 on the canaries already then...
[15:54:56] <_joe_>	 ah nevermind
[15:55:03] <_joe_>	 I think it's a bug of debdeploy
[15:55:13] <_joe_>	 it's saying "these hosts are already up to date" 
[15:55:18] <_joe_>	 but it's actually applying the change
[15:56:19] <_joe_>	 moritzm: yes confirmed
[16:27:58] <cdanis>	 when did debian decide that distutils wasn't a core part of python
[16:34:16] <volans>	 maybe because it's deprecated? https://docs.python.org/3/library/distutils.html
[16:41:57] <_joe_>	 cdanis: 'debian continues its war on its users'
[16:43:10] <cdanis>	 volans: so why even support installing python3.8 or 3.9 then?
[16:43:21] <cdanis>	 if you can't even invoke pip using it it once installed
[16:43:56] <cdanis>	 you can install python3-distutils which only includes the library for python 3.10
[16:43:58] <cdanis>	 very useful
[16:44:53] <volans>	 cit. """Its functionality for specifying package builds has already been completely replaced by third-party packages setuptools and packaging"""
[16:44:56] <volans>	 :-P
[16:45:28] <cdanis>	 tell that to my unittests checking for backwards compatibility
[16:46:36] <volans>	 our CI is perfect for that, tests only 3.7 and 3.8 :-P
[16:48:23] <_joe_>	 cdanis: yeah it's super annoying on sid
[16:48:56] <_joe_>	 if you find the right solution... I've resorted to using containers to test old pythons (where old means "not current")
[16:49:17] <cdanis>	 yeah, I think that is probably the best easy answer
[16:49:23] <cdanis>	 for now I will just run tests for 3.10 locally and let CI do the rest
[16:49:26] <volans>	 does pyenv work on sid?
[16:50:16] <_joe_>	 you won't troll me into learning yet another of those devlish things like rvm
[17:14:46] <paravoid>	 cdanis: https://people.debian.org/~paravoid/python-all/
[17:15:02] <paravoid>	 I've stopped maintaining it for some time now, but if you need anything I can resume
[17:15:21] <paravoid>	 I've rolled back some of the splits the python package does to allow coinstallability
[17:15:31] <paravoid>	 and I had talked to doko (python maintainer) to maybe fix that in general
[17:56:33] <jynus>	 You will see an alert saying "No backups: 105 hosts" -- that is totally normal
[17:57:12] <jynus>	 the new backups have been renamed and the check only checks the latest identifier
[17:57:29] <jynus>	 but older backups are still available for restoration
[17:57:59] <jynus>	 the alert will be fixed this week when as new backups are ran under the new name
[21:00:54] <denisse|m>	 Hello team, I wanted to upgrade the kernel of an instance using a cumin cookbook. The instance rebooted successfully however, the kernel was not updated.
[21:01:16] <denisse|m>	 This is the command I used: # cookbook sre.hosts.upgrade-and-reboot netmon1003.wikimedia.org --depool-cmd="systemctl stop librenms-poller-all.service" --repool-cmd="systemctl start librenms-poller-all.service"
[21:01:26] <denisse|m>	 Did I miss any steps in regards to the update? :O
[21:07:48] <mutante>	 denisse|m: I think you are already on the fixed version
[21:07:51] <mutante>	 ii  linux-image-5.10.0-17-amd64          5.10.136-1 
[21:22:29] <mutante>	 denisse|m: maybe we can merge Moritz' change to switch the rancid user to systemd:sysuser,+1 from both of us.. if you want to