[08:18:24] <taavi>	 I'm deploying https://gerrit.wikimedia.org/r/c/operations/homer/public/+/992244 - please ping me if you see any openstack api connectivity issues
[09:09:55] <dcaro>	 ack
[09:24:03] <blancadesal>	 dcaro: for https://gitlab.wikimedia.org/repos/cloud/toolforge/lima-kilo/-/merge_requests/94, does it have to be tested with the patches in the other repos it depends on? 
[09:24:55] <dcaro>	 blancadesal: kinda yes, otherwise toolforge-deploy would not work, or you could not run toolforge-jobs
[09:26:23] <blancadesal>	 on its own, I should still be able to sudo -i -u local.tf-test or not?
[09:39:58] <dcaro>	 you still need the toolforge-deploy fix, otherwise it will fail to deploy anything on k8s
[09:40:22] <dcaro>	 but yep, it should get to create the VM and the users iirc
[09:44:02] <blancadesal>	 hmm, looks like ansible isn't picking up the changes when I re-run the playbook
[09:45:07] <dcaro>	 do you have the mount on lima-vm, or using the copy on vagrant?
[09:45:21] <blancadesal>	 I was testing on vagrant
[09:45:44] <dcaro>	 then what you have is just a copy of the playbooks when you created the VM
[09:45:59] <dcaro>	 (if you are using the config as is)
[09:46:29] <blancadesal>	 ah, got it
[11:40:55] <topranks>	 XioNoX: fyi I followed up on the cloudelastic stuff, be interested to get your thoughts on the options 
[11:41:07] <topranks>	 https://phabricator.wikimedia.org/T346946#9480561
[12:57:31] <XioNoX>	 topranks: commented :)
[14:51:58] <taavi>	 upgrading cadvisor still increases memory usage on the prometheus nodes, so I'm reverting
[15:22:22] <taavi>	 think I figured it out - new cadvisor version brings new things that need to be disabled. https://gitlab.wikimedia.org/repos/cloud/toolforge/wmcs-k8s-metrics/-/merge_requests/7
[16:04:20] <taavi>	 I might not make it to our sync today. the most noteworthy thing is that cloudrabbit1003 was moved and I re-imaged it to the new network setup. I still need to figure out how to deal with the rabbit cluster, since extending the existing cluster across the two setups is not straightforward
[16:13:19] <andrewbogott>	 taavi: if it's too messy to cluster across the boundary I'd just leave it out of the cluster, move a second one, and then make /that/ the new cluster
[17:09:20] * dcaro off