Rush wrote on 2014-09-02 15:41:40 (UTC)

Phabricator should link them all

qgil wrote on 2014-09-03 10:18:55 (UTC)

The draft timeline at T282 has set the migration of RT by Sept 22-26. Is Ops ready for this, or do we need special communications with this team?

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:

• https://phabricator.wikimedia.org/T39#21719
• https://phabricator.wikimedia.org/T41#22638

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.

In T38#844238, @Dzahn wrote:

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.

found it. see T674 i'm gonna link it here

removing redirect blockers as we can't do it with leaving procurement behind and per @mark it is ok to not redirect URL's for RT

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 SRE 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.

The above is confusing, WMF-NDA will not be able to edit _policy_ on these tasks. As the policy UI is globally restricted.

In T38#848875, @chasemp wrote:

my understanding is that the hw-decomission queue is overlap with existing queues as far as current process and can be left behind.

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 	access-requests@rt.wikimedia.org/access-requests@rt.wikimedia.org 	60-90 	14 	Enabled
21 	codfw 	Dallas, Texas DC on-site work 	codfw@rt.wikimedia.org/codfw-comment@rt.wikimedia.org 	0-50 	0 	Enabled
5 	core-ops 	Core operations 	core-ops@rt.wikimedia.org/core-ops-comment@rt.wikimedia.org 	50-50 	0 	Enabled
13 	domains 	Domain registration queue 	domains@rt.wikimedia.org/domains-comment@rt.wikimedia.org 	0-50 	30 	Enabled
12 	eqiad 	Ashburn Virginia DC on-site work 	eqiad@rt.wikimedia.org/eqiad-comment@rt.wikimedia.org 	50-50 	0 	Enabled
6 	esams 	Amsterdam DC on-site work 	esams@rt.wikimedia.org/esams-comment@rt.wikimedia.org 	50-50 	0 	Enabled
19 	legal 	legal-related requests 	legal@rt.wikimedia.org/legal-comment@rt.wikimedia.org 	0-0 	0 	Enabled
14 	maint-announce 	Service maintenance announcements by service providers 	maint-announce@wikimedia.org/maint-announce-comment@rt.wikimedia.org 	0-0 	0 	Enabled
4 	network 	Network management 	network@rt.wikimedia.org/network-comment@rt.wikimedia.org 	50-50 	0 	Enabled
15 	ops-requests 	Operations Requests 	ops-requests@wikimedia.org/ops-requests-comment@wikimedia.org 	50-0 	3 	Enabled
3 	pmtpa 	Tampa, Florida DC on-site work 	pmtpa@rt.wikimedia.org/pmtpa-comment@rt.wikimedia.org 	50-50 	0 	Enabled
9 	procurement 	Procurement of data center equipment 	procurement@rt.wikimedia.org/procurement-comment@rt.wikimedia.org 	50-50 	0 	Enabled
8 	security-announce 	Security Announcements 	security-announce@rt.wikimedia.org/security-announce-comment@rt.wikimedia.org 	60-90 	3 	Enabled
7 	todo 	Personal TO-DO items 	todo@rt.wikimedia.org/todo-comment@rt.wikimedia.org 	50-50 	0 	Enabled
16 	ulsfo 	San Francisco, California DC on-site work 	ulsfo@rt.wikimedia.org/ulsfo-comment@rt.wikimedia.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
security-announce: ??
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
legal: unused
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)

In T38#850184, @Dzahn wrote:

do you still see it? how about we just move all the tickets from there to core-ops before import and done?

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.

"update docs" is the last open subtask? call this resolved yet?

so it seems we decided to not import the domains queue. should/can i manually move an open ticket i was still working on?

@Dzahn, I would just ask @mark if he's cool w/ that?

In T38#939694, @Dzahn wrote:

so it seems we decided to not import the domains queue. should/can i manually move an open ticket i was still working on?

meanwhile there is T87465 to request that as a new project

I think this ticket is technically not done. Reason: we can't shutdown RT because procurement tickets have not been imported and Robh needs them. please see T119112#2225259

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.

blocked by the procurement queue issues and maybe T118176

Cannot see all subtasks but I guess this task could be closed as resolved now?

Though, only the major ticket queues have been imported to Phab and not really all tickets.

In T38#4840473, @Dzahn wrote:

Though, only the major ticket queues have been imported to Phab and not really all tickets.

I didn't think we were going to migrate the rest, should this be re-opened?

@RobH I guess it's "rejected", i just wanted to point out it was never fully done so people are aware of that.