983242 - Better/more realistic staging environment for hg (and potentially git)

Status: NEW

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Laura Thomson :laura]

Let's get a good place to test plugins and upgrades, not just for correctness but for load.

Comment 1

[Kendall Libby [:fubar] (he/him)]

At a minimum, an ssh node and a separate web head. Will eventually want to also have the same in PHX1 to work out any DC replication issues (most of which will be moving write access around, but I could see running into timing issues between scl3/phx1/aws).

And yes, git should also get the same treatment, imnsho.

Comment 2

[Ben Kero [:bkero]]

We do have (inexplicably) hgstage1.dmz.scl3.mozilla.com and hgssh.stage.dmz.scl3.mozilla.com as staging areas for testing changes.

Unfortunately we've been unable to get a set of criteria with which to validate our changes from release engineering. The procedure before has been to make changes to these hosts, then ask (usually Callek) to poke at it to see if something is awry. This is largely why these hosts have gone unused.

We also do have git1.stage.dmz.scl3.mozilla.com, which mirrors production git puppet configuration (although not data). No requirements or big changes have necessitated using this host in months. It also lacks a validation strategy similar to hg.

Comment 3

[Gregory Szorc [:gps]]

We recently established https://hg.mozilla.org/hgcustom/version-control-tools/ for holding more of Mozilla's version control infrastructure (both server and client) in a unified repo. That would be a good place to hold:

a) Code that could set up a mock server environment (using Vagrant, Docker, whatever)
b) A testing and conformance suite that could be run against any server