EngineeringProductivity/Projects/MozReview/Deployment

(Bugs to be added as filed)

Systems required

[DB] (bug 1045190) MySQL database server. Minimum size: 20 GB (?)

• Software required:
  • MySQL.

[HG] Hg server. Minimum size: 20 GB. Ideally bare metal with an SSD.

• Software required:
  • Mercurial 3.0+.
  • hgweb

[RB] Webhead. Can be VM, size not a particular issue.

• Software required:
  • Review Board + extensions (see below).

Network flows

• RB -> DB:3306
• RB -> HG:443 (definitely needed?)
• RB -> Bugzilla:443
• RB:443 open to Internet

• HG -> hg.mozilla.org:80
• HG:22 open to Internet
• HG:80 and/or HG:443 open to Internet

Review Board application setup

Unlike dev & staging, we will rely on released versions of Review Board, since all functionality we require has been added to core or moved to extensions. We require at least Review Board 2.0.4, though I am told we should wait until 2.0.5.

If at all possible, something newer than RHEL 6.0 would be vastly preferred.

See official Review Board Linux installation and upgrade instructions.

The web head will also require our extensions, rbbz and rbmozui. These are currently found in the version-control-tools repo found at http://hg.mozilla.org/hgcustom/version-control-tools in pylib. The simplest deployment/upgrade scenario for those would be to pull from source and just run "python setup.py install" (with appropriate arguments) in pylib/rbbz and pylib/rbmozui.

BIG NOTE: Unless bug 1013156 is fixed before deployment, which seems unlikely due to its complexity, after the database is first set up but *before* anyone uses the system, the database schema must be manually updated to increase the length of several fields. This is terrible, but Django's username, full name, and email fields are much shorter than Bugzilla's, and it isn't easy to fix this. Specifically, the length of the varchar auth_user.username, auth_user.first_name, and auth_user.email fields all must be increased to 255 characters.

There is a lot of code in https://hg.mozilla.org/hgcustom/version-control-tools/ that creates a nearly full stack testing environment. We would ideally like as much of the deployment code to live in this repository as possible so developers can reproduce the production environment as closely as possible so development and testing can be as similar to production as possible. This will help us move faster.

Other

• Security review pending (bug 978976).