qgil wrote on 2014-05-13 00:47:10 (UTC)

Assigning to Rush, who will decide the way forward.

qgil wrote on 2014-05-13 18:49:08 (UTC)

Thought: since the very beginning our Phabricator instance in production should have

• only the admins that really need and deserve to be admins (i.e. not me)
• only the applications we are going to use in Day 1
• only the configuration changes that we want for Day 1
• no testing content

In other words, nothing like this Labs instance, devoted to learning, testing, and play around.

dzahn wrote on 2014-05-13 23:40:58 (UTC)

if we actually do this (tracking tickets that aren't just for playing around) in this phab instance, then we need to also import the content of alpha-phab to beta-phab to prod-phab or something or we will not have any history.

that's why i'd say we should use the old systems (Bugzilla, RT) until we are done switching

dzahn wrote on 2014-05-13 23:45:09 (UTC)

install phab in production https://rt.wikimedia.org/Ticket/Display.html?id=7483

• i created new projects/repos in gerrit after talking to Chase and Chad

15:27 < mutante> ssh -p 29418 gerrit.wikimedia.org gerrit create-project --require-change-id --owner=ldap/operations --parent=operations --description='"command line

interface for phabricator"' phabricator/arcanist

there is phabricator/phabricator, and phabricator/arcanist and phabricator/libphutil .. Chad will look at the permissions and moving it under operations

create db for phab https://rt.wikimedia.org/Ticket/Display.html?id=7484

it turns out phabricator wants to have "one db per application" which was a bit unexpected. the list it created on the labs instance is

so we can't just ask our DBA Sean to make "a DB" as i expected. instead we need to figure out which apps within phab we are actually going to use, before it is installed in production prefarably

dzahn wrote on 2014-05-13 23:49:36 (UTC)

Where exactly are we going to install it

on "iridium"

and will we have a testing instance or work directly in a production server?

no manual work on production servers needed if the workflow is that we puppetize it, apply class on test instance, then if we like it, apply same instance on prod instance. yes, we should have a new test instance from scratch, but that doesn't cost anything

dzahn wrote on 2014-05-13 23:53:04 (UTC)

i can also use Bugzilla if you want me to, but i'd like to avoid these things:

having to update progress about phabricator setup in 3 places

updating in this phab instance and then deleting it or having to import it elsewhere

aklapper wrote on 2014-05-16 22:04:54 (UTC)

In T142 it was decided to go with phab.wikimedia.org as the URL.

aklapper wrote on 2014-05-16 23:21:46 (UTC)

updating in this phab instance and then deleting it or having to import it elsewhere

We'll import relevant/"real" tickets from this Phabricator Labs instance into the Phabricator production instance (see T336 for discussing it) after importing Bugzilla tickets (to keep the ID mapping).

aklapper wrote on 2014-05-28 17:28:45 (UTC)

Looking at https://rt.wikimedia.org/Ticket/Display.html?id=7483 I don't see any news since the day of creation either.

@Rush: Could you please share / clarify plans here? Has some work been done and the ticket needs updating, or is anything blocking going ahead which needs more thoughts or input from others?

Does this first require defining which apps within Phab we are going to use, as stated earlier (so is that blocking process here)?

Rush wrote on 2014-05-29 15:07:39 (UTC)

@aklapper...hey!

I sent this email last week:

Valued and Beloved  Colleagues and Greg-g,

Per request I am going to summarize the current and loose status of this journey, or at least my understanding of it.

Assertions:

* Phabricator is coming (for some things at least)[0].

* We have a labs instances[2].

* The labs instance has kind of become a runaway train, in that it was a POC that got real-ish data.

* Several pieces of this migration cannot easily be tested in labs due to sensitive data[3]

* We have a thread going in gerrit for making sure Phabricator is managed by Puppet [1].

* The basic timeline for fire to follow all of this smoke is before the 'end of summer'.

* Bugzilla[6] things need to redirect appropriately to their counterpart ticket in Final Phabricator.

* 'Day 1'[4] Phabricator is defined a single, production, secure, migrated,
           homogeneous, login integrated, ticket and bug reporting platform.

* We have some security oriented use cases not being met by Phabricator currently[5].

A Loose Plan For Phabricating:

0.   Assign initial hardware for Phabricator in production

1.  Create forks internally in Git for our internal Phabricator

2.  Flush out the Phabricator module in Puppet and test in Labs

3.  Deploy Phabricator via Puppet using production resources and internal git forks

4.  Invite people/teams on a limited basis who are currently in ticketing limbo, or who would like to be early adopters,
    to use our Alpha-Phabricator instance that is in production.  Data in this instance
    is considered production, and migration will be planned accordingly.  It may be only a few of us
    using it for real work, and that is ok.  It may be numerous people who want to get into the
    flow and that is ok too.  This will not be a 'what does this button do install?', but it will
    also not be a 'we have everything ready to go to for every user' install either.  Several teams
    that should be good candidates have expressed interest, which is part of the catalyst for this
    style of rollout.

5.  Create migration scripts for Bugzilla => Phabricator using our Alpha instance.  It is the
    intention for phab.wmf.com/123 to be the old bugzilla.wmf.com/123 issue.  That may mean
    we have to import all Bugzilla data first so we can reserve ticket number space, but not necessarily.
    Phabricator does allow for some custom fields which we could potentially redirect on and it would be
    the same effect and history.  No decision has been made.  No technical solutions have
    been tested.

6.  Create migration scripts for RT => phabricator.  Most of these tickets have not been
    vetted for sensitive data so we may need to find a few that can be opened up if the security
    solutions have not been finalized.  The intention, as I understand it within Operations,
    is for RT tickets to move over as-is in sensitive data mode and be vetted individually
    to be moved into the public space.  Hopefully, over time less is behind the veil,
    but at the outset it has to be that way.

7.  At this point we have a migration script to get data from Bugzilla, a script to get data from RT,
    and, if we can get some people in the sandbox, some data in Alpha that has been tracking real projects
    and real work.  We will backup the existing Alpha, install our Production Phabricator, import Bugzilla,
    import RT, import Alpha data, and away we go.  Some questions remain: Won't the Alpha data and the
    Bugzilla data conflict in ticket numbers?  Maybe.  The current thinking is we can compensate before restoring
    Alpha data and/or use a less blunt force method to make old Bugzilla tickets redirect.  Why not wait
    and make a production instance when we have the migration scripts already done?  We could do that, and I believe
    everyone is free to adopt that mindset, but I also think there is a real need to build a knowledge base
    internally and generate some goodwill regarding the tooling.  A staggered integration which starts with
    users who are enthusiastic that can translate their positive experiences, and help provide onboarding, is
    going to lead to the most positive general rollout.  All is up for discussion.

8.  Consider the obvious folly of steps 1-7 in hindsight.

Currently:

* Mukunda is working with upstream on making headway for the security needs.

* Operations (mostly myself and daniel for now) are spearheading the Phabricator install

* We have picked a team (mostly self elected) to admin Phabricator itself

* We need some people with Bugzilla / RT chops to start figuring out data export

* We need some people who want to learn about the Phabricator API to figure out data import

* We need some people with authentication chops to figure out login (I think csteipp is on this?)

* qgil has the general outline of all moving parts regarding this in far better detail

* Alpha is a few weeks away, as we are tied up in pre-Phab commitments.  I believe according to
the basic timeline that fits within the overall scheme.  We are somewhere between steps 1 and 2.

Hopefully, I have improved the conditions of this discussion and not muddied the waters further.

Thanks,

Chase Pettet
Operations Engineer

0. https://www.mediawiki.org/wiki/Phabricator/Plan#Migration_plan
1: https://gerrit.wikimedia.org/r/#/c/132505/
2. fab.wmflabs.org
3. http://fab.wmflabs.org/T63
4. http://fab.wmflabs.org/project/view/31/
5. http://fab.wmflabs.org/T95
6. http://fab.wmflabs.org/T39


https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/Plan

I'm currently locked up in a large account refactoring.

mmodell wrote on 2014-05-29 18:47:17 (UTC)

a bit of a status update from my end:

I'm currently working on phabricator in vagrant because it seemed like the easiest way forward for me personally. I've got phabricator partially puppetized and working on hooking up MediaWiki auth in the vm.

I'm also tackling the security reports issue which probably isn't going to happen upstream any time soon so we'll be stuck maintaining a small patch for the time being. It won't be terribly messy though so I'm not too worried about the maintenance becoming a time-sink.

Once I'm done with these tasks I'll be blocked by ops getting some production hardware/environment set up, hopefully my vagrant puppetization of phabricator will be applicable to the production environment without too many changes. We'll see I guess, I'm at least attempting to make it compatible with operations/puppet.

Rush wrote on 2014-05-29 19:18:18 (UTC)

@mmodell

nice man, maybe use labs instead so we can tinker together if necessary?

qgil wrote on 2014-06-02 21:59:50 (UTC)

We have a change in our plans introduced by Trusted User Tool, a small project (compared to Day 1) that will become the first customer of Phabricator. In short, we need a real Phabricator instance in production with only Wikimedia SUL and Legalpad enabled, as soon as possible.

I think this step actually goes in the same direction that @Rush wants to go: starting to play with Phabricator with real fire before Day 1 and heavyweight Bugzilla deprecation. As soon as the Wikimedia SUL and Legalpad parts are clear, we could enable Maniphest and open a controlled test inviting just a few projects with basially no overlap with Bugzilla, as Rush proposed. The difference would be that this real test would be done in the 100% definitive production server, not in a transitional production server. One step less.

What do you think?

aklapper wrote on 2014-06-03 14:47:06 (UTC)

Rush: Thanks for the summary (I didn't follow that private mailing list closely enough); this progress is lovely to hear and good to see explained here in public. Thanks guys.

we could enable Maniphest and open a controlled test inviting just a few projects with basically no overlap with Bugzilla

If a Phabricator production instance with enabled Maniphest is available, task numbers will get assigned.
We'd want Bugzilla ID 12345 to become Maniphest T12345 for simpler redirect rules (T65, T334).
I expect ~70000 Bugzilla and ~10000 RT tickets to migrate into Phabricator.

@mmodell: Do you know if starting with T100000 for newly filed tasks in a fresh Phabricator instance would be possible, and to import tickets from other systems into T1-T99999 later?

qgil wrote on 2014-06-03 15:34:08 (UTC)

This is a discussion for T334: Document RCStream in the Developer Hub

qgil wrote on 2014-06-03 15:36:40 (UTC)

@Rush, when do you think we can have a bare bones Phabricator instance in production, with only Wikimedia SUL and Legalpad?

aklapper wrote on 2014-06-03 16:10:00 (UTC)

For the records, https://gerrit.wikimedia.org/r/#/c/132505/ is the commit for "initial commit for a phabricator module (WIP)" being worked on.

qgil wrote on 2014-06-04 22:46:50 (UTC)

This is how my proposed changes could fit in @Rush's deployment plan:

In T294#24, @Rush wrote:

A Loose Plan For Phabricating:

0. Assign initial hardware for Phabricator in production

1. Create forks internally in Git for our internal Phabricator

2. Flush out the Phabricator module in Puppet and test in Labs

3. Deploy Phabricator via Puppet using production resources and internal git forks

This alpha Phabricator intance would have Wikimedia SUL only. We would test it as much as we feel confident.

3.5 Enable Trusted User Tool (Legalpad + tweaks) before enabling any Maniphest. Keep considering this an alpha, keep considering the data as production, to be migrated to the final instance.

As soon as we are confident about Trusted User Tool...

4. Invite people/teams on a limited basis who are currently in ticketing limbo, or who would like to be early adopters, to use our Alpha-Phabricator instance that is in production. Data in this instance is considered production, and migration will be planned accordingly. It may be only a few of us using it for real work, and that is ok. It may be numerous people who want to get into the flow and that is ok too. This will not be a 'what does this button do install?', but it will also not be a 'we have everything ready to go to for every user' install either. Several teams that should be good candidates have expressed interest, which is part of the catalyst for this style of rollout.

5. Create migration scripts for Bugzilla => Phabricator using our Alpha instance. It is the intention for phab.wmf.com/123 to be the old bugzilla.wmf.com/123 issue. That may mean we have to import all Bugzilla data first so we can reserve ticket number space, but not necessarily. Phabricator does allow for some custom fields which we could potentially redirect on and it would be the same effect and history. No decision has been made. No technical solutions have been tested.

6. Create migration scripts for RT => phabricator. Most of these tickets have not been vetted for sensitive data so we may need to find a few that can be opened up if the security solutions have not been finalized. The intention, as I understand it within Operations, is for RT tickets to move over as-is in sensitive data mode and be vetted individually to be moved into the public space. Hopefully, over time less is behind the veil, but at the outset it has to be that way.

7. At this point we have a migration script to get data from Bugzilla, a script to get data from RT, and, if we can get some people in the sandbox, some data in Alpha that has been tracking real projects and real work. We will backup the existing Alpha, install our Production Phabricator, import Bugzilla, import RT, import Alpha data, and away we go. Some questions remain: Won't the Alpha data and the Bugzilla data conflict in ticket numbers? Maybe. The current thinking is we can compensate before restoring Alpha data and/or use a less blunt force method to make old Bugzilla tickets redirect. Why not wait and make a production instance when we have the migration scripts already done? We could do that, and I believe everyone is free to adopt that mindset, but I also think there is a real need to build a knowledge base internally and generate some goodwill regarding the tooling. A staggered integration which starts with users who are enthusiastic that can translate their positive experiences, and help provide onboarding, is going to lead to the most positive general rollout. All is up for discussion.

8. Consider the obvious folly of steps 1-7 in hindsight.

Does this make sense?

qgil wrote on 2014-08-14 12:10:00 (UTC)

Can you estimate how long will it take to complete step 2 in the migration plan, aka setting up a Phabricator instance in production?

Looking at the list of blockers of this task, there are two that doesn't seem to be actual blockers: T410: Update regexes in Gerrit conf to support auto-linking to Phab tickets in commit messages in Gerrit web UI and T423: Create list of performance-related improvements for Jenkins jobs. Migration related tasks are part of of the next step, right?

qgil wrote on 2014-08-15 11:34:39 (UTC)

As per T334#17, the current list of Blocked By tasks seems to be accurate. An official bless from Rush & Andre would be helpful to know that we are on the good path toward Step 2 in the migration plan.

aklapper wrote on 2014-08-20 16:22:22 (UTC)

In T294#62, @Qgil wrote:

As per T334#17, the current list of Blocked By tasks seems to be accurate. An official bless from Rush & Andre would be helpful to know that we are on the good path toward Step 2 in the migration plan.

Official bless, refering to the "Blocked by" list in T294. We identified two more blockers today (T552 after a conversation with Chris; and T553 already being worked on but didn't have a local reference in fab.wmflabs.org, my fault), it's not enitrely clear yet how easy T336 will be, and for T423 we ran into an unexpected issue (bug in Bugzilla's Webservice API; we might need to exclude such Bugzilla tickets and import them manually).

Still, currently end of September 2014 is the expected date for resolving this ticket as fixed.

Rush wrote on 2014-08-27 19:40:22 (UTC)

this task became confused and doesn't make sense for how we have things organized overall by projects. I am decoupling this and removing to reduce confusion. all work for setting things up is tracked in independent tasks.

aklapper wrote on 2014-08-27 20:07:46 (UTC)

...and who wants to keep track, please now see http://fab.wmflabs.org/T282 and http://fab.wmflabs.org/project/board/31/

importing issue status