[01:38:42] Hi, anyone here knows if it's possible for a continuous job to create another job with jsub? [01:46:09] !help [01:46:09] MarioFinale: 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 [11:17:39] I would say so [13:37:04] Hi, I got email related to deprecating Ubuntu on toolforge. What I should do? [13:37:09] !help [13:37:10] Zoranzoki21: 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 [13:51:08] Zoranzoki21: Please provide more and complete information? [13:51:24] Zoranzoki21: You should do what is written in that email, probably. [13:51:40] andre__: I found on wikitech.wikimedia.org everything is ok now [13:51:43] https://wikitech.wikimedia.org/wiki/News/Trusty_deprecation [13:52:02] which has been announced many times, so if you have a specific question please ask a specific question. Thanks! :) [14:25:04] Hi everyone, `select rev_comment from revision where rev_id=16855390`@cswiki_p gives an empty string, although the revision has some summary/comment. Is rev_comment field not working nowadays? Or is this a bug? [15:58:08] Urbanecm: I'd have to check docs, but I believe it has been moved to a different table [15:58:58] chicocvenancio, yeah, to "comment", but I thought rev_comment will look into comment internally [16:00:25] rev_comment was also using a temp table that may have gone away. It might need attention. [16:00:40] That whole process has been chugging along. [16:07:38] I'll have to look at that. rev_comment might (in fact, I think very likely), need an update on that table [16:07:50] Urbanecm: ^^ [16:08:35] thanks bstorm_ [16:08:40] is there any task tracking this "issue"? [16:09:03] Well, first, are we using revision or revision_compat tables? [16:09:35] Because if we are using revision, this is all as designed. They stopped writing to the rev_comment field. [16:10:10] the compat table does the tracking of comment [16:10:14] My query uses revision [16:10:27] but I thought toolforge's views are going to search for the comment internally [16:10:54] We had to move that logic to revision_compat because it made the standard revision table too slow [16:11:08] aha, thanks bstorm_ [16:11:31] However, this might end up flipflopping because the compat table might end up faster than comment for other reasons 😰 [16:12:02] does revision_compat contain everything that revision? [16:12:10] Yes [16:12:36] so there's no difference than the rev_comment field? [16:12:39] It is supposed to simply keep the old schema available, despite being slower [16:12:52] I see, thanks [16:13:19] It should be the same, yes. It might need an update due to temp table changes...but I don't *thing* so yet? [16:13:25] *think* so [16:14:08] There's no task yes specifically around that...but there should be one popping up before the table is dropped so I think I am safe for now 😆 [16:14:23] I didn't know about revision_compat (it looks it wasn't announced on cloud/cloud-announce at all), so... [16:14:35] does that mean revision_compat is to be dropped at some point? [16:16:47] It's more that I created it as an alternative if changing a tool seemed harder than changing the table with regard to the updates to the db schema in mediawiki [16:17:27] thanks [16:17:29] So compat tables are supposed to be there to help tool maintainers who might not be available or have time to refactor to use the joins needed for the new schema [16:17:42] Not many use them now [16:18:05] I see [16:18:50] I can't say how long we'll keep them. I'm concerned about other things in the performance of the views as is...and they might be needed in one sense or another in the near future as more people find empty fields in places like rev_comment [16:19:27] So no plans for them to go away so far, is what I'm saying :) [16:20:20] thanks [17:11:33] !log admin moving all VPS dynamic proxies to proxy-eqiad1.wmflabs.org aka proxy-01.project-proxy.eqiad.wmflabs, as per T213540 [17:11:36] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [17:11:36] T213540: Migrate nova proxies to eqiad1 - https://phabricator.wikimedia.org/T213540 [19:12:34] !log admin moving the VPS proxy API backend to proxy-01.project-proxy.eqiad.wmflabs, as per T213540 [19:12:37] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [19:12:37] T213540: Migrate nova proxies to eqiad1 - https://phabricator.wikimedia.org/T213540 [20:00:00] !log admin VPS proxies are now running in eqiad1 on proxy-01. Old VMs will wait a bit for deletion. T213540 [20:00:02] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [20:00:03] T213540: Migrate nova proxies to eqiad1 - https://phabricator.wikimedia.org/T213540