Work out any kinks in the mailing list replacement process by creating a new cloud-admin mailman list and archiving the current labs-admin mailman list.
The members and general configuration of the existing labs-admin list should be copied to the new cloud-admin list and verified before the older list is archived.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| redirect labs-admin to cloud-admin mailing list | operations/puppet | production | +1 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | bd808 | T166404 Program 10 Outcome 2: Rebranding | |||
| Resolved | bd808 | T168480 Perform core Cloud Services rebranding | |||
| Resolved | RobH | T167155 Create cloud-admin and archive labs-admin mailing list |
We want to make sure that the existing list archives redirect transparently to the new list archives. This is probably the biggest deal in the renaming process. We really don't want to break all links to labs-l archives that are on wikis and in Phabricator.
Anytime an mbox file is touched, if anything was removed since the last re-compile, it can change the links. Also it will require downtime on the mailman server to accomplish. If the archives are private, moving the list name is better than my below alternative.
Alternative: the old list could be left in place, shut down, and just linked to the archives. (This is only a good idea when archives are public. If it is a private archive, then leaving them in place and abandoned tends to cause access issues in the future for those archives.) A new list with a new name could be created, and the membership list copied over. This would require no downtime on the host. This wouldn't seemlessly link them, the old url would still work normally for archives. Again though, if the archives are private, this is non ideal.
@RobH, you certainly have more experience with this sort of thing than I do. If creating new lists and archiving the old lists is the safe way to rename then lets do it that way. I think you are describing is basically option 1 from https://wiki.list.org/DOC/4.70%20How%20do%20I%20change%20the%20name%20of%20(rename)%20a%20list%3F
Task description has been changed to describe a create and archive change rather than a rename.
Chatted with BD about this via irc, will attempt to get to this later today/tomorrow.
Ok, removed my old comment, it was incorrect.
The new list is in place with settings and Chase has the new admin email sent to him. I've left the old list in place and functioning for now, due to @Quiddity's email requesting that the new list receive the old lists emails.
Is that a requirement for this change? Does the new list have to process the old lists to address? (I saw no requirement for this to keep the old archives intact, not a requirement for redirection of new emails.)
Adding @herron as he has done quite a bit of mailman work recently and may have insight.
Can't we just rename it? I think there was a command for that?
Edit: yep, I've found https://wikitech.wikimedia.org/wiki/Mailman#Rename_a_mailing_list
Yes, but it requires scheduled downtime of the mailman server and opsen who are comfortable renaming a list. I'm happy to give it a shot, but I've not used the script, only done it manually awhile back. Renaming means the mbox file is touched, which also means it can reindex the entire archives and old links could break.
https://wikitech.wikimedia.org/wiki/Mailman#Rename_a_mailing_list has some details. The mbox reindexing is not always going to happen, but it tends to more often than not. Considering the comment below, it seems pretty important they not reindex, but I've almost always seen it do so. Renaming means downtime and possibly reindexing of archives.
While I put the new list in place, it seems it may have been premature. I've pulled the new list off the server until we figure it out!
The need to halt all of mailman for in-place renaming seemed to be unnecessarily impactful to me. The create, copy, and archive approach seems much less likely to cause larger issues.
I did forget/neglect to document that it would be ideal for the old list alias to continue to deliver to the new list. In the case of the admin and announce lists that is really not a big deal, but for T175190: Create cloud mailman list and archive labs-l list it will be.
The old list alias can continue to deliver to the new list alias by our inclusion of it in operations/puppet:/modules/profile/files/exim/listserver_aliases. That should put in the mail redirection for the old address to the new list. (That is what its seems used for in other cases.) I'd want to have us plan to test it when it is done though.
@bd808: Since you are the manager for cloud, I'll take your say as final on how to accomplish this. It seems the following:
This should accomplish what you want on cloud-admin, as well as hopefully what is needed for the conversion of the old labs-l list as well. (It seems best to try it out on this lower traffic list first!)
@bd808: Does this seem reasonable to you?
Change 381052 had a related patch set uploaded (by RobH; owner: RobH):
[operations/puppet@production] redirect labs-admin to cloud-admin mailing list
Ok, I've setup an alias for the redirection, and disabled the old mailing list.
emails to the new list work, will merge the patch live and test old list redirection
Change 381052 merged by RobH:
[operations/puppet@production] redirect labs-admin to cloud-admin mailing list
We've gotten this working now. All emails sent to labs-admin@lists.wikimedia.org automatically forward into cloud-admin@lists.wikimedia.org without any special actions needed to be taken by any parties.
The old archives should remain intact. Please test everything out, since this will be how we move over the other lists.
Steps taken:
I'm assigning this to @bd808 for his followup and approval. If this all tests and works as you want, we can handle the other labs => cloud list migrations in the same method.
Everything looks good to me.
I announced the list name change: https://lists.wikimedia.org/pipermail/cloud-admin/2017-September/000004.html