@Jhernandez just presented survey results that show that ~40% of our users aren't subscribed to cloud-announce.
We should pursue some way of making cloud-announce subscription automatic for wmcs users. Ideally, auto-subscribe when they get their first project membership and unsubscribe when they're removed from their last project.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T278361 auto-subscribe cloud-vps and/or toolforge users to cloud-announce | |||
| Open | None | T279023 Expose mailman3 internal REST API inside Wikimedia production network | |||
| Restricted Task |
The easiest solution is to implement a everyone@wmcloud.org alias, (with some only allowing mails via cloud-announce@lists.wm.o protection), and subscribe it to the list. The upsides are it can all be done on the Cloud side and has no dependencies on the specific version of mailman. The downside is that many people will use different emails for mailing lists and 60% of users would get double emails!
More involved is to have Horizon and/or Striker subscribe people when they join. In mailman2 you'd have to do shell stuff on the lists server, mailman3 has straightforward APIs to do it (but they currently aren't exposed due to a lack of usecase).
It sounds like @Ladsgroup is hard at work getting mailman 3 up and running in prod; I've been thinking that this task should be paused pending that work. Or is it already up and ready to roll?
Lego is doing most of the work these days (I'm more of a cheerleader/emotional support these days). Mailman3 will be accessible soon (hopefully) maybe a couple of months. I assume this ticket is not high priority but OTOH, getting the mailman3's API to be exposed to the cloud might be complicated (security-wise, implementation is easy) I think this needs more thinking. We can have a "bot"-like set of script living in lists1001.wikimedia.org interacting with the API. Wouldn't be too hard. What do you think @Legoktm?
I don't think this will be a concern; all the relevant user management will be happening in Keystone which runs in production space -- as long as the APIs are exposed to internal networks it shouldn't be complicated/dangerous to access to them from there.
Filed T279023: Expose mailman3 internal REST API inside Wikimedia production network. I would like to see what access control options exist on the mailman side, but it definitely should be doable.
A few months later, I don't really want to expose Mailman's REST API internally anymore.
Instead I propose: