Page MenuHomePhabricator

Add bigdelete to OTRS Wiki bureaucrats
Open, LowPublic

Description

We are currently in a situation where we may need to delete and recreate a couple of our long-running pages. As such, could we assign "bigdelete" to the bureaucrats user group on OTRS Wiki?

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 627964 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[operations/mediawiki-config@master] Grant OTRSwiki sysops bigdelete

https://gerrit.wikimedia.org/r/627964

DannyS712 moved this task from Backlog to To deploy on the Wikimedia-Site-requests board.

Scheduled for BACON - Thursday, September 17 18:00–19:00 UTC

@DannyS712 Awesome, thank you for taking care of that!

Urbanecm added a project: Performance-Team.
Urbanecm added a subscriber: Urbanecm.

Hey, a deployer running the window @DannyS712 scheduled this for speaking. I did not deploy this patch today, because it touches bigdelete, which can easily be a source of many performance problems (it can easily make the number of writes much more higher).

I'm tagging Performance-Team, as this touches the area of performance. Could one of you comment on this, please?

This seems fine from our team's perspective. I don't see an operational risk with this because we have protection measures in place that kill POST requests that take too long (and thus will never commit such dangerous lag-inducing database query), and we also have write query limitations that will rollback any database transaction that takes took long.

However, that would likely mean it will show users a button that doesn't work, so I can't really sign off on the main request here as to whether the feature makes sense to enable.

Tagging Platform Engineering where Tim and Bill who have refactored the page deletion process last year to use the job queue in batches. Can you confirm that that indeed works in production and applies to the bigdelete feature?

@Krinkle Hmm... I feel your comment kinda contradicts itself: If the bigdelete feature uses job queue (and I think it does), the POST request would be very short, regardless on the size of the pages. The page deletion happens in batches per T198176, which would mean that write queries would be "bearably short" (but there can be a lot of them). Or am I missing something obvious?

@Matthewrbowker To fix the immediate problem, I have granted bigdelete to the local steward group that exists at all wikis. Since most stewards have some sort of OTRS access, they should be able to grant steward group to them locally, do bigdeletes, and then revoke the group. Feel free to ping me or any other steward to process the deletes similary to what we do at content wikis.

This seems reasonable

I'm sorry, what is "this" exactly?

This seems reasonable

I'm sorry, what is "this" exactly?

{{ping}} any updates on whether this can proceed?

Maybe the perf team could way in on this

Maybe the perf team could way in on this

already did, above

This seems fine from our team's perspective. I don't see an operational risk with this because we have protection measures in place that kill POST requests that take too long (and thus will never commit such dangerous lag-inducing database query), and we also have write query limitations that will rollback any database transaction that takes took long.