@Lina_Farid_WMDE Something still needs to be merged for that to work. It's in code review. It will be done soon though.

Thanks! I added Lina to WMF-NDA in Phabricator for access to private tickets.

@KFrancis Could you add Lina to the 'NDA and MOU' spreadsheet please? That way Brett can see the email address and we don't run into sync issues like with T358578. Thanks

Your experimental patch (https://gerrit.wikimedia.org/r/c/operations/puppet/+/1019066/1/hieradata/role/common/prometheus/pop.yaml right?) is also removing the "sni_support: strict" line.

new bullseye deployment server runs into known issue T257317 with scap init again

This is comparing the existing envoy config between a main DC prometheus (2005) with a POP prometheus (3003).

Ok, fair enough about the tracking task. But don't we still need some kind of task that someone can take to do the actual upgrade work? So all the subtasks without the tracking parent task?

In T363360#9742998, @Hghani wrote:

My contract expiry date is June 30th 2024. I believe the contact should be @OSefu-WMF.

well known effect that happens a couple hours after gitlab upgrades. this one caused specifically by https://phabricator.wikimedia.org/T363349#9742369

https://community-crm.wikimedia.org/ is now online 🎉

The email address contains the -ctr suffix. For contractors please provide an expiry_date and expiry_contact. On that date we will ask if the access should be removed or extended.

created new subtask about deployment servers on bullseye in general - stalled on that

@Muehlenhoff Where does deploy* (deployment_server role both prod and wmcs) fit in? Since we are still on buster there. But want bullseye deployment_servers in cloud VPS projects and production hasn't upgraded the role yet. A legit subtask for here?

per comments on https://gerrit.wikimedia.org/r/c/operations/puppet/+/820749/14/modules/scap/manifests/master.pp#69 (Thanks Ahmon Dancy) - added profile::mediawiki::scap_client::is_master: true to deploy-prefix Hiera which fixes the duplicate declaration related to scap init on deploy-1006. machine started.

deploy-1006 is on bullseye and the current status is "puppet error with duplicate declaration related to initializing scap" and would be the first deployment_server on bullseye - so issues are expected

created new "puppet prefix" in Horizon called "deploy" - then used it to apply role and needed Hiera keys for a deployment server to all hosts starting with deploy*

Things have been working better since we gave it more resources. Closing again for now.

@DMburugu please approve if you can confirm :)

https://www.wikidata.org/wiki/Q125573461

https://www.wikidata.org/wiki/Q125573425

https://www.wikidata.org/wiki/Q125573400

Ah, so the point is mostly that it should not be public information who signed the agreement?

https://www.wikidata.org/wiki/Q125573207

I don't see how you would appropriately control access on a wiki.

In T360964#9718714, @hashar wrote:

gerrit-prod-1001.devtools.eqiad1.wikimedia.cloud can be deleted: was shutdown because Gerrit used T330312. I used that for Scap development and testing Gerrit upgrade. Nothing needed there

Recently both the old buster Gerrit instance in devtools AND the newer bullseye test instance were deleted in T360964#9718714.

@Izno Wanna tell me what you dislike about it? Would there really be a difference whether people sign something here or on a wiki?

According to CodeSearch, affected images are:

@BTullis I tried this myself as well, I created /tmp/dzahn and ran the command manually as root, just pointing to my dir and I get the files with timestamps April 19.

In T351202#9682432, @Urbanecm wrote:

..it changes e-mail addresses of several stewards to another one, which is not intended. I changed users.yaml and re-ran the script; the dry run should now be empty.

Sending a single mail to multiple lists at once have always been discouraged though, to be honest.

Here is some archeology about that and why I had this memory.

I was probably mistaken. It was enabled way back in T656 in the early days of Phabricator at WMF and started out on a Labs instance. It think WMF might have also paid Phacility for development / support back then but not sure, this made me use that phrasing.

setting priority to low - to get it out of "untriaged incoming SRE tickets list". Just guessing based on the way the ticket is phrased and the age of it. Of course not trying to tell the team or subscribers how to actually prioritize as they see fit.

I made the following edits to the "Volunteer NDA" docs to reflect this change:

over at T349595#9598075 the L2 document has been retired and it has now been made official that NDA requests should go through Legal directly and signing L2 in Legalpad is not part of that process anymore

@KFrancis Thank you very much and apologies as well for the delay on my side.

@Muhammad_Yasser_Jazirahly_WMDE Are you (still) interested in getting access to private Phabricator tickets or do you not need this? Please let me know. Best, Daniel

Check was deleted in https://gerrit.wikimedia.org/r/c/operations/puppet/+/885288 by Giuseppe

This was about https://gerrit.wikimedia.org/r/c/operations/puppet/+/668166/2/modules/profile/manifests/mediawiki/alerts.pp but now this seems all deleted from the puppet repo.

This instance was deleted recently per https://wikitech.wikimedia.org/wiki/Nova_Resource:Mailman/SAL

who to contact about managing the archives of old lists

Based on Ladsgroup's comment above I suggest closing this as declined.

latest comment on T345809 and the merge from October 2023 sound like this is basically declined?