[07:36:21] mutante: spicerack has already an icinga.remove_downtime(), if needed you can just create a simple cookbook to use it [09:16:27] akosiaris: you around? [09:17:30] arturo: yup, how can I help? [09:18:01] in toolforge, our front proxy (dynamicproxy) uses a debian package `kubernetes-node` which points to you [09:18:18] that is debian jessie, and I'm working on giving support to the puppet code for buster [09:18:30] I'm wonder what happens with `kubernetes-nodes` pkg in buster [09:18:45] I'm wondering* [09:19:08] we haven't visited that yet (buster support) but I should be able to unblock you relatively easily (as long as you don't have specific version requirements) [09:19:44] I guess a simple rebuild would do the trick? [09:19:47] Version: 1.4.6-7 [09:19:47] Provides: cadvisor [09:19:47] Depends: libc6 (>= 2.3.2), adduser, docker.io | docker-engine [09:19:47] Recommends: kubernetes-client [09:20:02] ouch [09:20:04] 1.4? [09:20:33] https://www.irccloud.com/pastebin/VX3ceb4g/ [09:20:40] you are going to try and add support for 1.4 on buster? [09:21:14] not really. I'm just migrating the puppet code to buster so we can later migrate to our newer k8s cluster [09:21:35] which wont require dynamicproxy to know anything about k8s (bc ingress) [09:21:50] so is something like migrate-to-deprecate [09:21:59] ok, so would it be ok if the package was 1.12.9-1 instead? [09:22:44] I guess it depends on what the new masters are on [09:22:58] I think we only use kube-proxy from this package [09:23:20] still, kube-proxy needs to talk to the API [09:23:25] but yes, the old master wont see a version upgrade [09:25:23] so wait, lemme get this straight. The new cluster running 1.1X.whatever is ready, but there is that component that is the dynamic proxy that uses kube-proxy to direct external traffic to the pods. That is to be removed at some point, but first we need to migrate the underlying OS to buster? [09:27:51] dynamicproxy (or toolforge front proxy) not only does proxy for the legacy k8s, but also for the web grid in grid engine. That's why we need to keep it around [09:28:07] and is jessie, so we need to upgrade it to something newer anyway [09:28:33] at some point that front proxy will be supporting 3 "backends": web grid, legacy k8s, new k8s [09:28:45] so we can reallocate users from the legacy k8s to the new one [09:29:32] so, migrating to buster and giving support for the new k8s are only soft-related [09:29:51] ok, so essentially you want a kubernetes-node package for 1.4.6 for some time [09:30:02] exactly [09:30:08] (in buster) [09:32:35] that's relatively easy, the only thing I am concerned about is the reprepro component we should put it under. I 'd like it if it wasn't in the main component so that we avoid any kind of interference with a future buster production. So if we can amend that puppet code to add some component foo/bar (e.g. tools/legacy-k8s), fine by me [09:33:05] that makes sense [09:33:07] we should be able to btw, our code is full of those componets [09:33:37] for this "short-lived" package we may also consider using our internal toolforge aptly repo? [09:34:04] sure, if that suits you better, it's a perfectly valid approach as well [09:34:29] I think so [09:35:14] for a quick unblock I might just copypaste the pkg into our aptly repo [09:35:20] funnily enough, it's golang btw. There is a good chance the package might work as is [09:35:30] heh [09:35:37] so yeah +1 on that quick unblock [09:36:32] so this turns out to be a: nevermind! :-P [09:36:38] thanks!!! [09:36:41] lol [09:36:43] yw [09:36:48] thanks as well for reaching out [09:37:17] 👍 [17:29:39] volans: oh! very nice. thank you (re: icinga.remove_downtime) [17:37:25] volans: to add docs for "change mgmt pass" i added section on the page you made for IPMI https://wikitech.wikimedia.org/wiki/Management_Interfaces#Change_the_mgmt_password and then there is also a ticket by ema about documenting IPMI stuff on wikitech i just ran across after that https://phabricator.wikimedia.org/T191956 and that links to like 5 other pages but not this one :) [17:38:02] so far i just left a comment to look at Management_Interfaces. it has the best "how to fix IPMI".. stuff you wrote [17:38:31] maybe i should point srodlund to this. technical writer [17:39:17] or just merge the old pages into sections of the new page to start with [17:40:15] oh, wow. i dont even need to point her to it. "srodlund moved this task from Backlog to New Technical Documentation Request on the Documentation board.". :) [17:55:51] mutante: great, yeah I wrote teh Management_Interfaces one a while ago and added an alias for IPMI, so if you search ipmi in wikitech it goes there [17:56:50] I saw the edit, no strong preferences there as long as we try to keep all the doc together [18:12:49] volans: https://phabricator.wikimedia.org/T191956#5567125 [18:13:29] thanks!