[10:36:54] T432586 actually seems more like jobs-api is totally broken =\ [10:36:55] T432586: [jobs-cli] tab completion is broken - https://phabricator.wikimedia.org/T432586 [10:37:26] ok, just for that tool... so I'll keep it on the ticket [11:21:24] I'm suddenly getting this message when trying to start a job on Toolforge: "OneOffJobs can't be updated, delete and recreate it instead". `toolforge jobs delete`/`restart` both say: "ERROR: Job 'make-declarations-wle-2022' does not exist". I tried with a job that ran fine last week and now I get this. Anyone knows why that is, has something changed [11:21:24] with jobs recently? [11:22:52] Here's the command I run to start: `toolforge jobs load --job make-declarations-wle-2022 batches/5M.yaml`. [11:24:14] The tool is commonsdb-registry. [11:29:26] I forgot that all the parameters were in the config, not the command. Here they are: [11:29:27] ``` [11:29:27] - name: make-declarations-wle-2022 [11:29:28]   command: env HOME=/workspace src/make_declaration.py -t mem:2.0Gi -t cpu:0.5 -t version:0.1.17 --verbose batch:category-116146619 [11:29:28]   image: tool-commonsdb-registry/tool-commonsdb-registry:latest [11:29:29]   cpu: '0.5' [11:29:29]   mem: 2.0Gi [11:29:30]   emails: all [11:29:30]   filelog: True [11:29:31]   mount: all [11:29:31]   retry: 5 [11:29:32] ``` [11:35:54] `load` always does a job update (even if it's a creation) and there was a recent split of the logic in jobs-api, which enforced one off not being updatable... I guess it's being typed as that due to `retry`, probably jobs-cli should treat that as a creation (POST) not update (PATCH) which would appease the API. dcaro that seems to be some slight fallout from your split [11:39:55] also, please use a pastebin (such as https://phabricator.wikimedia.org/paste/) instead of pasting multi-line files here directly [11:40:22] Gotcha. [11:40:33] FYI: It worked when I built a command that did the same as the job in the config and ran that. [11:52:07] Sebastian-WMSE: that's interesting, so you are using jobs load to start one-off jobs? [11:52:21] Yes. [11:53:15] I would like to know more, as we are thinking on what to do with one-off jobs, one option is to allow you to define them (so they will show up in jobs list), and then trigger them when you want to start them [11:54:05] Damianz: yep, you are right, that is a fallout from the split, I'll open a task for it [12:21:44] !log tools.wikibugs Updated channels.yaml to: 855ab59e0a3c427c4a0460ba0f1df4b20864f21eb9439a886f6f16b13013cd9e [12:21:46] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [12:43:10] !log tools.wikibugs Updated gerrit-channels.yaml to: f30065c45b80543d21ea36f42f0d441652f7676a3addad9ced53b1cc37abb6c0 [12:43:13] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [15:18:11] Is there a tool like Dependabot in GitLab Wikimedia? [15:19:21] Is there a guide for RevovateBot? [15:42:01] I feel like this is probably more to do with production than the replicas specifically, but it would be super nice if user_registration didn't have nulls in the user table. Counting revisions for a user is sometimes slow (and optimising queries through the views is generally painful) [15:47:09] I feel like if the user registration date is null you can infer it was a really long time ago [15:47:28] Like pre-2005 or so [15:48:21] <_Gerges> @countcount: Hi, Is there a guide for RevovateBot? [16:03:11] !log jeanfred@tools-bastion-15 tools.integraality Deploy 2fa79d1 (Fix QLever link in SSE error UI: add SPARQL prefixes) for T425477 [16:03:13] !log jeanfred@tools-bastion-15 tools.integraality Deploy 4235204 (Show SPARQL queries in SSE progress messages) for T425477 [16:03:15] backfilling was done for accounts that edited prior to user_registration, but obviously there are a bunch of accounts that didn't edit before then [16:03:15] !log jeanfred@tools-bastion-15 tools.integraality Deploy a4029f2 (Mark completed steps with ✅ via DOM mutation) for T425477 [16:03:15] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [16:03:17] !log jeanfred@tools-bastion-15 tools.integraality Deploy 7dbac6d (Make streaming update the default) for T425477 [16:03:18] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [16:03:20] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [16:03:22] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [16:20:13] @erges404 https://www.mediawiki.org/wiki/LibUp is what we use for a lot of Gerrit repos. I don't know that anyone has taught that bot to work on GitLab yet. That is sort of ironic with the bot itself being gitlab hosted. [16:22:13] given that mediawiki itself will not be moving to gitlab, i do not think libup will be supporting that anytime soon [17:00:25] !log jeanfred@tools-bastion-15 tools.integraality Deploy b3e24a6 (Log all totals and no-grouping SPARQL queries in SSE stream) for T425477 [17:00:27] !log jeanfred@tools-bastion-15 tools.integraality Deploy dd7677a (Fix footer layout: use sticky footer instead of fixed position) [17:00:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [17:00:29] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [20:29:13] Hi! I run a mailcow instance on WMCS and could use some input on IPv6 reverse DNS. We already have a PTR set up for our floating IPv4 (185.15.56.85 -> mail.wikimedia.az, done via T421025). Our instance also sends mail over its IPv6 address, which currently has an auto-generated PTR (mail.azwikimedia.eqiad1.wikimedia.cloud) instead of mail.wikimedia.az. Since IPv6 [20:29:13] addresses here a [20:29:13] ren't floating, is there a way to get a custom PTR set for it anyway, similar to what was done for our IPv4? [20:31:34] (this is for Gmail deliverability -- Google Postmaster Tools flags SPF as "needs work" when mail goes out over IPv6 with a mismatched PTR, even though SPF/DKIM/DMARC all pass in the headers. Trying to get reverse DNS aligned so Gmail doesn't treat the IPv6 path as suspicious.) [21:36:20] is there a "src_set" for a firewall::service that matches the hosts running the web proxies in front of cloud VPS, by any chance? [21:36:48] !log jeanfred@tools-bastion-15 tools.integraality Deploy 14ca09e (Collapse completed sections in SSE progress view) for T425477 [21:36:52] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [21:37:15] mutante: CACHES [21:37:32] taavi: ah! thanks [22:24:30] @nemoralis: I think a phabricator task will work out better for discussing your issue than the telegram<->irc bridge here. [22:26:37] I think ultimately what you want/need is an IPv6 PTR record in https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/blob/main/resources/eqiad1-r/cloudinfra/dns.tf like the IPv4 one you got with the last task. The tricky bit may be figuring out the IPv6 to use and how to keep it updated.