Page MenuHomePhabricator

Add tooling to backpopulate instance accounts into the cluster
Closed, ResolvedPublic


The major barrier to the simple cases of account import is backpopulating instance accounts into the cluster. Specifically, we need a workflow which:

  • Identifies all unlinked, non-bot accounts on an instance.
  • With administrative oversight:
    • links accounts to existing cluster accounts based on email addresses (this is a potential security risk, so they need to be vetted);
    • creates new accounts in cases where no cluster account exists:
      • prompts to rename cluster accounts with name collisions;
      • creates the accounts;
      • creates an OAuth link;
      • creates an instance membership; and
      • allows one-time login mail to be sent.

Then we can import instance data in the simple case by:

  • importing a MySQL dump;
  • running account backpopulation;
  • everyone can now log in and everything works.

Revisions and Commits

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Phacility.
epriestley moved this task to Do After Launch on the Phacility board.
epriestley added a subscriber: epriestley.

Just a quick update here -- there are really two barriers:

  • Getting accounts sorted out (this task, T7522).
  • Letting users upload very large data archives in the gigabyte range (T7149).

I had figured we'd do something hacky/manual for the upload part, but it looks like we can actually build something pretty reasonable without an extraordinary amount of effort, so I've been building that out first. That has pushed this back a little bit -- I'd guess there are 1-2 days of work on large upload support, so I expect the account stuff will happen more like early next week.

epriestley added a commit: Restricted Diffusion Commit.Mar 17 2015, 3:37 PM
epriestley added a commit: Restricted Diffusion Commit.Mar 17 2015, 11:09 PM

I think I have this working locally and am nearly ready to give it a shot in the cluster.

One issue occurred to me: while we have a dry run instance running in the cluster, users would normally receive duplicate mail for commits (since both instances will import the commit, both will run rules, and both will send email, etc.)

We should either disable "dry run" instance daemons entirely (which also simplifies wiping repository data, although it wouldn't let repositories actually work), or disable mail (and eventually SMS).

Disabling mail is probably better, since it would be good to verify that repositories work fine.

This probably takes the form of a "silent" flag for instance services which makes SiteConfig select the "throw mail in a hole and forget about it" MTA adapter.

epriestley added a commit: Restricted Diffusion Commit.Mar 18 2015, 12:39 PM