- Mentioned In
- T874: Convert RT links in Bugzilla comments in links in Phabricator tasks
T123713: decom magnesium (was: Reinstall magnesium with jessie)
T41: Set up redirects from RT URLs to Phabricator
T32413: RT tickets hide status information from volunteers and staff alike
T48: Migrate RT tickets keeping the same access levels
- Mentioned Here
- T118176: migrate RT maint-announce into phabricator
T119112: move RT off of magnesium
T87465: create a project for tasks related to WMF domain names
T76990: Update wiki documentation related to RT
T674: need to figure out how to make an rt queue read-only
T282: Performance Testing Cluster
Rush wrote on 2014-08-29 13:17:40 (UTC)
@Qgil, we need a block of tasks to signify phabricator to production? The intro of legalpad and the heavy use of this instance has thrown some of the original timeline / plan / lingo into dissarray. The email I sent yesterday linked the "day 1" project as the group of tasks solely for phabricator to production. So making RT a part of that now is confusing. We can make what is now mostly day 1 as day 0 if it's more sensible for you, but I need a project that is not muddled by RT and Bugzilla for general phabricator work.
Can we remove these tasks from the day 1 or do something for this?
I now see on https://www.mediawiki.org/wiki/Phabricator#Migration_timeline that RT migration is now scheduled to happen *after* bugzilla migration, so bugzilla users are again used as first guinea pigs. Where can I read about the rationale for this? I've checked blockers and they don't seem blocked, though some questions could use answers by ops:
We have put a lot more hours, previews, feedback, and tests in Bugzilla than in RT. Furthermore, even if RT is smaller, it tuns out to have additional complexity because of the many more queues and statuses used there, and because of the different levels of permissions. Also, RT contains a lot more sensitive information than Bugzilla. This is why the idea of going with RT first seemed sensible in theory, but it wasn't in practice.
We changed our plan progressively. First it was clear that RT was first, then we said that we would g for whichever was ready first, and finally we decided to focus on Bugzilla.
Chase, you mentioned that you need the part "how to make one queue read-only". I thought there already was a ticket for that where i tried it out, but now I have a hard time finding that one.
Is the list of queues at https://wikitech.wikimedia.org/wiki/RT#Which_queues_do_we_have_and_what_are_they_used_for.3F up to date? Which are the queues that we are migrating? (or the ones we are not migrating, if you prefer a shorter answer) :)
Enabled queues for migration:
['codfw', 'ulsfo', 'pmtpa', 'ops-requests', 'network', 'esams', 'eqiad', 'core-ops',]
Notable queues (in use) left behind:
maint-announce, access-requests, and procurement
What's happening to hw-decommission ? Will that workflow move to phab? looks like there are recent tickets (in the last month) in the queue but they are spam.
Will tickets be manually reviewed/classified after import? what will the initial metadata be? (e.g. edit/view policies, cc lists)
my understanding is that the hw-decomission queue is overlap with existing queues as far as current process and can be left behind.
WMF-NDA will have view to all ported queues, and Operations will have edit. As of now the edit perms are global so we can't be more liberal than that, hopefully when Spaces comes together. Note, edit isn't required for commenting.
afaict that queue has not been used and we just did decom tickets in the corresponding datacenter queues.
i can't even see it in the UI anymore, at least not when i'm not root.
do you still see it? how about we just move all the tickets from there to core-ops before import and done?
logged in on RT as root to check existing queues. hw-decom doesn't exist anymore. "todo" can be ignored. these are left:
17 access-requests Access Requests email@example.comfirstname.lastname@example.org 60-90 14 Enabled 21 codfw Dallas, Texas DC on-site work email@example.comfirstname.lastname@example.org 0-50 0 Enabled 5 core-ops Core operations email@example.comfirstname.lastname@example.org 50-50 0 Enabled 13 domains Domain registration queue email@example.comfirstname.lastname@example.org 0-50 30 Enabled 12 eqiad Ashburn Virginia DC on-site work email@example.comfirstname.lastname@example.org 50-50 0 Enabled 6 esams Amsterdam DC on-site work email@example.comfirstname.lastname@example.org 50-50 0 Enabled 19 legal legal-related requests email@example.comfirstname.lastname@example.org 0-0 0 Enabled 14 maint-announce Service maintenance announcements by service providers email@example.comfirstname.lastname@example.org 0-0 0 Enabled 4 network Network management email@example.comfirstname.lastname@example.org 50-50 0 Enabled 15 ops-requests Operations Requests email@example.comfirstname.lastname@example.org 50-0 3 Enabled 3 pmtpa Tampa, Florida DC on-site work email@example.comfirstname.lastname@example.org 50-50 0 Enabled 9 procurement Procurement of data center equipment email@example.comfirstname.lastname@example.org 50-50 0 Enabled 8 security-announce Security Announcements email@example.comfirstname.lastname@example.org 60-90 3 Enabled 7 todo Personal TO-DO items email@example.comfirstname.lastname@example.org 50-50 0 Enabled 16 ulsfo San Francisco, California DC on-site work email@example.comfirstname.lastname@example.org 50-50 0 Enabled
access-requests: left behind per Chase
codfw: imported per Chase
core-ops: imported per Chase
domains: ? can move to legalpad.wm.org ??
eqiad: imported per Chase
esams: imported per Chase
legal: ? can move to legalpad.wm.org ??
maint-announce: left behind per Chase, would need incoming email enabled from anywhere
network: imported per Chase
ops-request: imported per Chase
pmtpa: imported per Chase
procurement:left behind per Chase
todo: i think we should ignore it, wasnt really used?
ulsfo: imported per Chase
domains: my understanding is that this is a sort of procurement queue and should be treated as such
security-announce: this one hasn't come up, but it's a sort of maint-announce for seclists? I am planning on treating it as such and leaving it behind.
todo: yep ignored (and also I don't have access to them)
domains: it would be _awesome_ if we could have a project for this in (any) phabricator instance, but it needs to have legal (Yana Welinder) and ops on it and sometimes it receives mail from MarkMonitor. i don't think it has much in common with procurement. Ops doesn't have the budget to buy domains anymore, legal has it. But we still need _something_ where we can coordinate tasks related to domain names (like adding it to DNS after legal told us they bought or won a domain etc).
legal: yea, unused, but that is unfortunate and we still need something like this. we need something where we can contact legal. be it legalpad.wm or something else
security-announce: unsure, maybe the best is to just forward it to security@wm mail alias
(re hw-decommission queue)
I can see tickets like https://rt.wikimedia.org/Ticket/Display.html?id=7832
No particular opinion about what to do with that content. just mentioned because it was a queue I could think of that was missing from the list.
So as @Dzahn pointed out, I need to regularly search and read the old procurement queue tickets in RT. These tickets also have file attachments that we need to parse and review for historical purchasing record.
If that queue can import from RT into S4, and keep its date/subject/content/file attachments/email data intact and searchable, it would work. We'll also have to be able to type in an old RT# and search/find the new phabricator task.