In T296847#8745352, @Xover wrote:

In T296847#8745191, @Ladsgroup wrote:

There would be a special page that you go and explicitly enter the domain you want to exempt for your account and part of installing such gadgets would be to go there and set it.

For this to be viable in practice this needs to be "GUI-able" for Gadgets. I.e. that they can prompt you for the opt-in, and the user click a check box ("Whitelist toolforge.org?"). Which probably means this facility needs to be provided by MW. Think "the OAuth confirmation dialog". Anything that requires manual editing of a MediaWiki:Whitelist-esque whitelist is a no-go for anything except a personal user script (possibly shared with a few other techies, but not for the general user base).

hmm, yeah, I think it should try relative path from $IP before erroring out. That makes it fully backward compatible.

Only these two left:

{
    "_metadata": {
        "time_end": 1680182552.852061,
        "time_start": 1680181902.3546872
    },
    "flaggedrevs fr_user field-unsigned-mismatch": {
        "s2": [
            "db1162:eowiki",
            "db1162:plwiki"
        ]
    }
}

Doing index hints on rc queries is quite complicated because it depends on the arguments user provides and how they interact and such :/

In T296847#8675001, @Bawolff wrote:

Eh.. the long-standing consensus has been that there are no exemptions. Is there an intention to change this?

There's some ambiguity about what circumstances users can opt-in to stuff, if they have given informed(-ish) consent. For example, the map layers on wikivoyage, or [not default enabled] gadgets that embed google translate. I assume that that sort of thing is what is being referred to.

FWIW, after three weeks of mobile PC entries getting cleaned up. I optimized most of the table in a spare pc host we had:
https://grafana.wikimedia.org/d/000000377/host-overview?orgId=1&var-server=pc1014&var-datasource=thanos&var-cluster=wmcs&from=1679772407075&to=1680263465303&viewPanel=28

Okay, I looked at it in depth and the sharding couldn't have caused these jumps (sorry, I was wrong). For two reasons: 1- The sharding is disabled by default and I'm not finding any config that enables it for the test wiki 2- The way that sharding works makes it that you will have temp user 4 before temp user 3 but no gaps.

Added now, in thirty minutes you should be able to access stat machines but someone from data engineering needs to do your krb creds.

Thanks <3 <3 <3

It was the issue that broke the script halfway through creating tickets. I fixed that. so it should be fine for the next ones.

Done now:

ladsgroup@mwmaint2002:~$ mwscript version.php --wiki=aawiki
MediaWiki version: 1.41.0-wmf.1 (built: 19:58, 20 March 2023)
ladsgroup@mwmaint2002:~$ mwscript Version --wiki=aawiki
MediaWiki version: 1.41.0-wmf.1 (built: 19:58, 20 March 2023)

Blocked on approval by owners of analytics-privatedata-users: @Ottomata or @odimitrijevic

Wrong section, sorry

In T706#8738862, @KSiebert wrote:

As an Engineering Manager I would need access as we won't have a Technical Program Manager as of next week.
Could I be added to Project-Admins so I can create tags, projects etc. I'm aware of the guidelines.

That'd be T331834: Prepare and check storage layer for ckbwiktionary. It'll take a bit to be properly sanitized for the cloud

Thank you for the note, it's actually not too unusual. For rev_comment migration we had the similar thing that a client wiki would read with its own config from wikidata's revision table (and *fireworks* ensues). I keep that in mind.

Is there anything left to do on SRE side? Otherwise we should remove the SRE tag.

I prefer to have something there to satisfy the gods of bureaucracy but it's not mandatory for wmde/wmf groups for new hires.

I need to wait for puppet to propagate and then I do the ldap changes in mwmaint.

That checklist is part of the process for giving the rights: https://wikitech.wikimedia.org/wiki/SRE/Clinic_Duty/Access_requests#LDAP_access

I did the filtering and now it's time to create the users before handing it over to data engineering

The wiki is live, any extra work should have its own ticket.

I was asked to comment on this. I'm not sure about the final design, product-wise but if you try to make it work as a QueryPage (an example: Special:WantedPages), it's going to be quite easy to build and maintain and you get all of the scalability protections (querying vslow, caching, etc.) for free and wouldn't need to worry about it at all. Something like this: https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialMostLinkedCategories.php. HTH

Hi, I guessed your email address via the WMDE's email pattern, can you please confirm this? https://gerrit.wikimedia.org/r/c/operations/puppet/+/903691/1/modules/admin/data/data.yaml

Thanks. I'm clinic duty this week.

I agree with bd808. I prefer first finishing the retro before adding more responsibilities to it.

It seems there was another regular job was needed to sync users in ldap with grafana. @fgiunchedi thankfully did a manual kick:

Amir1: Mar 28 13:39:18 grafana1002 grafana-ldap-users-sync[25538]: INFO:__main__:Created user babiola name Barakat Ajadi email babiola-ctr@wikimedia.org
15:40 should work now on retry

They are now in the list in https://ldap.toolforge.org/group/wmf

User:Barakat Ajadi (more info)

There are a couple more warnings still https://logstash.wikimedia.org/goto/b3869e1ef82447c9fd65f7abee8f1279

They show up in ldap search:

ladsgroup@mwmaint2002:~$ ldapsearch -x cn=wmf
...
member: uid=babiola,ou=people,dc=wikimedia,dc=org

They aren't showing up in https://ldap.toolforge.org/group/wmf maybe I messed up something in ldap change. Let me double check

Does this need anything from SRE now? I assume Hugh already took care of the most.

Maybe adding user-notice, feel free to remove if you think it's not that important.

Merged and deployed the patch, it should be doable in half an hour.

you'll have access with the new keys in thirty minutes

@matej_suchanek Let me know if you need help in any step of the way. You can also start testing first with beta cluster and then test wikis.

Clinic duty this week, it doesn't need the full process. Let me double check something and get back to you.

I added Barakat to wmf ldap group. They should be able to access grafana and such.

oh thanks. That means it'll take a month or two at most (after schema change patch getting merged in core)

Will do it once some clean ups are in place.

repeating what I said in the meeting with Daniel. If it's using the same general backend (MySQL PC), only splitting it via even fragmentation should just work out of the box. They are distributed via consistent hashing so it'll be in a random different (or the same in some cases) physical host. That makes it homogeneous and easy to maintain instead of maintaining two separate clusters.

Yup, adding a new column is not that hard. There are some documentation on this https://wikitech.wikimedia.org/wiki/Schema_changes and https://www.mediawiki.org/wiki/Manual:Schema_changes

I'm planning to overhaul the documentation regarding this soon. Stay tuned.

https://wikitech.wikimedia.org/wiki/Deployments/Training

I'm on clinic duty this week. Waiting for signoff by Tyler. Maybe a deployment training can be arranged (or other devs in wmde can do an informal training)

superset should be automatically done via wmf ldap group. If Jgiannelos is in the ldap group, it should be done already. Correct?

Martin was busy so I did it.

This is actually done already as part of T313253: Fix Flaggedrevs database schema drifts in production

In T332329#8728312, @Lucas_Werkmeister_WMDE wrote:

You’re both talking about the wrong extension / class. EntitySchema’s SqlIdGenerator works on a database table that only has one row, and doesn’t have an id_type column. The id_value is the only column in the table – there’s nothing else we even could use to address any specific row.

It got merged today, I'm planning to deploy this tomorrow and until then it shouldn't be closed, otherwise people might see the warning and create it again.

Yeah to me it really feels like it should be avoided and I see it as a good opportunity to discourage it. You can set the id_type in the where condition?

https://logstash.wikimedia.org/goto/b3869e1ef82447c9fd65f7abee8f1279

I'm already doing this as part of the main one. I just need to do switchovers in eqiad and we will be done with this too

Timo is working on devtools now: https://gerrit.wikimedia.org/r/c/labs/codesearch/+/902880

FWIW these are characters that can be found in a standard Persian keyboard (as a way to check for universality of the choice): !٬٫﷼٪×،*)(ـ+÷؟|

I'll add it: https://github.com/wikimedia/labs-codesearch/blob/master/write_config.py