Sounds like a good idea. Is this to address a specific concern that came up? One thing that comes to mind is the amount, readability and relevance of the information, e.g. maybe it would make sense to only limit this to directories the account has write access to (tricky for root)? Some UX testing would be nice :)

In T267365#6736390, @ArielGlenn wrote:

To clarify, are we talking about urls of the form upload.wikimedia.org/something (or lang.project.org/something.php?somethingelse... or swift urls?

Thanks, let us know when the database is created, so we can sanitize it.

@Esanders could you help me understand what impact this is expected to have on the parser cache databases?

Thanks!

@Jclark-ctr @Cmjohnson, what's a realistic ETA for completing the work on these servers? It would help us plan the next steps for this quarter.

@gmodena Manuel will be around tomorrow, we can sync up on exact timing then. Will that work?

@gmodena Manuel is not around today, could we postpone this?

Thanks, let us know when the database is created, so we can sanitize it.

I moved the backup hosts to https://phabricator.wikimedia.org/T271148.

• heze.codfw.wmnet will be deprecated (planned in Q3).
• ms-be and ms-fe are media storage and not managed by us (yet). @fgiunchedi, could you comment on these?

Thanks, let us know when the database is created, so we can sanitize it.

Thanks, let us know when the database is created, so we can sanitize it.

@ArielGlenn will look into whether URLs can be extracted for deleted images and what the alternatives are if not.

Thanks, let us know when the database is created, so we can sanitize it.

Thanks, let us know when the database is created, so we can sanitize it.

As discussed last week, this task needs to be estimated and scheduled. It's not currently considered to be a workflow blocker.

Reopening based on @Ladsgroup's comment.

Thanks, let us know when the database is created, so we can sanitize it.

Thanks, let us know when the database is created, so we can sanitize it.

Thanks, let us know when the database is created, so we can sanitize it.

Is the documentation merging / overhaul tracked anywhere (in a task, perhaps)? Seems like a good opportunity to ask :)

Thanks!

@Cmjohnson Would it be possible to plan for racking 5 instead of 3 of the new hosts in one go? It would help us prepare fot Sanitarium host Buster/10.4 upgrades, which are currently at risk due to issues tracked in https://phabricator.wikimedia.org/T268742. Any 1G rack locations are fine for the 2 additional hosts.

@Jclark-ctr based on the DC entry schedule, when do you expect you will be able to take a look at this? Knowing this would allow us to better plan next steps regarding backup source locations.

I believe the key questions to DBA have been answered so I'm removing the team tag. Please add us back if there is anything else we can help with.

Thanks, let us know when the database is created, so we can sanitize it.

Removing DBA, please add us back if there are any additional questions we can answer in this task. Alternatively, create a new task to monitor the table size once the change is deployed.

https://phabricator.wikimedia.org/T265321 was resolved last week so the ipblocks_restrictions alter should no longer be necessary.

Thanks, let us know when the database is created, so we can sanitize it.

I don't believe there is an explicit action for DBA here so I'm untagging us from this task. Please add us back if there are specific questions we can help with.

@jbond What is your preferred delivery date for this?

@jbond What is your preferred delivery date for this?

Cheeky question, should we go with a "clouddb" user and role to be consistent or would that be too much work to untangle from the current set up?

Is it clear what the underlying problem was and how it was fixed? Just making sure it's not phantom recovery.

@kostajh what is your preferred time horizon for this DB to be available?

This host is ready for DC-Ops to decommission.