[00:12:42] !log tools T213353 Added 36 exec nodes to the new grid [00:12:47] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [00:12:47] T213353: Scale out Son of Grid Engine/Stretch exec nodes - https://phabricator.wikimedia.org/T213353 [10:35:46] !log tools deleted non-puppetized checks from tools-checker-{01,02} [10:35:48] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [15:37:19] !log redirects moving project to eqiad1-r [15:37:20] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Redirects/SAL [15:53:50] do we have logrotate in toolforge? [15:55:55] Hauskatze: if your question is if it is easy to use logrotate on grid job log files, sadly the answer is no. Its possible but complicated [15:56:18] * bd808 looks for the bug that has workarounds [15:56:42] bd808: yeah, that was mostly my question. I wanted to rotate the redirect.py logs the grid jobs generate so they don't grow too big [15:57:03] I'll keem rm'ing then, then [15:58:03] Hauskatze: using "copytruncate" is the magic bit -- https://phabricator.wikimedia.org/T68623#2012498 [16:00:30] bd808: I guess we cannot setup a 'sudo' user to do it? [16:00:41] Hauskatze: an `rm` while the tool is running actually ends up orphaning the log file. The grid engine process keeps the inode open and keeps writing to it [16:01:12] I rm when the job has finished :) [16:05:11] that works :) any logrotate command would work then too. the copytruncate part is only needed to rotate the logs for a live grid job [16:06:16] bd808: so in my case logrotate is an option? [16:06:24] my bot is not continuously running [16:07:13] yeah, you could setup a local logrotate config file and run it as your tool user either manually or via cron [16:07:56] tears of joy - thanks! [16:08:34] * Hauskatze will fetch logrotate docs and will try something [17:05:56] !help Hello all! I am mapping edits performed on articles in 271 by geolocating unregistered IP addresses. But, I want to exclude IP edits that are vandalism. I was thinking of using the ipblocks table for each language and exclude those IP addresses that are permanently blocked. Does anyone have a better suggestion? I'm all ears. [17:05:56] tomthirteen: If you don't get a response in 15-30 minutes, please create a phabricator task -- https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=wmcs-team [17:06:53] tomthirteen: that might get better responses as an email to the cloud@lists.wikimedia.org discussion list, but thanks for thinking about asking for other ideas :) [17:09:37] bd808: I understand. Thank you. I've tried that before and never seem to get an answer. I've always gotten great help here. That's why I asked. [17:10:02] *nod* and you still might :) [17:11:03] You guys are the best. [17:25:11] Hi all, I'm running into a problem with k8s on toolforge. I'm using this yaml , but the replicaset stays at "1 desired" and doesn't actually create the pods. [17:35:53] Zhaofeng_Li: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes#Container_images [17:43:22] Zhaofeng_Li: if gtirloni's link is not clear for you, we do not allow 'bring your own' Docker containers at this time [17:48:55] gtirloni, bd808: Hmm, now that's awkward. I suppose I'll have to rely on docker-registry.tools.wmflabs.org/toollabs-python-web and friends, right? [18:03:09] bd808: thanks for being helpful :-) [18:03:52] Zhaofeng_Li: yes [18:07:16] Zhaofeng_Li, by the way, thanks again both for your tool, and work over the years, and recent post at enwiki. <3 :) [18:13:15] Zhaofeng_Li, you might also want to file a phab task with that co-maintainer request (place it under the "Maintainer needed" column in https://phabricator.wikimedia.org/project/view/2457/ ) and announce the request on cloud@ mailing list. That might help. [18:17:37] quiddity: No problem, and I still want to apologize for my unannounced departure. It wasn't a fun experience, but maybe I need to grow thicker skin and have fun working with Wikipedians again. I'll post a request on phab shortly. [18:18:01] Regarding k8s on Tools, so it hasn't really changed much in 2 years. I'd really want the ability to push to this registry, or the option to supply Dockerfiles so images can be built on Labs, enforcing the open source guideline. The way it's currently set up doesn't really allow us to take advantage of the convenience and reproducibility of Docker, now that we're mounting the actual executable code into the containers themselves. [18:31:21] Zhaofeng_Li: I agree with your desires. I continue to hope for progress on a more robust support for custom containers, but the reality is that we have not had the capacity on the Cloud Services team to advance this yet. [18:54:37] !log tools T213355 built and configured two more generic web nodes for the new grid [18:54:41] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [18:54:41] T213355: Scale out Son of Grid Engine/Stretch webgrid-generic nodes - https://phabricator.wikimedia.org/T213355 [19:16:31] !log tools.zoranzoki21wiki Created https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/3589 - T201491 [19:16:34] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.zoranzoki21wiki/SAL [19:16:34] T201491: Fix common typos in code - https://phabricator.wikimedia.org/T201491 [20:33:04] akosiaris, fyi I noticed a question here [non-urgent] https://wikitech.wikimedia.org/wiki/Talk:Streamlined_Service_Delivery_Design [21:06:31] quiddity: ah thanks [22:45:03] !log tools T213357 - Added 24 lighttpd nodes tot he new grid [22:45:07] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [22:45:08] T213357: Scale out Son of Grid Engine/Stretch webgrid-lighttpd nodes - https://phabricator.wikimedia.org/T213357