In bug 1398236 we're going to change Balrog's dev and stage environments to be more in line with Cloud Ops standards, and more useful for staging Releases. The dev environment will be like the current stage environment, and autodeploy whenever changes are merged to master. The new stage environment will autodeploy whenever we push a tag that doesn't match "latest" or "master-" to dockerhub. We already create tags like "v2.xx" on Github as part of the release process, so we should do the same on Dockerhub so that stage gets updated just before we ship to prod. Bonus points if we can make Taskcluster do it in response to Github tags. Both new environments will support database resets as well. Dev will do this when a "migrate-dev" tag is changed on dockerhub, and stage will do it in response to "migrate-stage" tag changes. We don't need to automate creation of these tags - a human can do it whenever needed. Let's make sure this is documented, though.

We came up with a better idea for the db resets pretty quickly: a special endpoint that nginx intercepts, and triggers the reset: 17:27 < relud> bhearsum: what do you think of hitting https://balrog-admin.stage.mozaws.net/__dbreset__ to trigger the migration (which nginx would intercept and call a script for)? 17:27 <~bhearsum> oh, that's even better 17:27 <~bhearsum> maybe require a magic string in the query params to prevent accidents? 17:28 <~bhearsum> eg: https://balrog-admin.stage.mozaws.net/__dbreset__?YESREALLY=1

I just posted https://github.com/mozilla/balrog/pull/399 which _should_ contain all of the CI changes needed to do this. Past that, I also need to: - Create the necessary roles in Taskcluster to make Release events work. - Update the docs to talk about creating a Release in Github rather than simply pushing a tag. Because we're going with an HTTP interface that nginx handles for the database resets, there's nothing we need to do besides bug 1376331 to suppor that.

(In reply to Ben Hearsum (:bhearsum) from comment #2) > I just posted https://github.com/mozilla/balrog/pull/399 which _should_ > contain all of the CI changes needed to do this. > > Past that, I also need to: > - Create the necessary roles in Taskcluster to make Release events work. > - Update the docs to talk about creating a Release in Github rather than > simply pushing a tag. > > Because we're going with an HTTP interface that nginx handles for the > database resets, there's nothing we need to do besides bug 1376331 to suppor > that. Reading over things again, I think we actually may need a command in run.sh to reset the db. That's pretty scary since it could, in theory, be run for production. We'll need to find a way to safeguard it...

(In reply to Ben Hearsum (:bhearsum) from comment #3) > (In reply to Ben Hearsum (:bhearsum) from comment #2) > > I just posted https://github.com/mozilla/balrog/pull/399 which _should_ > > contain all of the CI changes needed to do this. > > > > Past that, I also need to: > > - Create the necessary roles in Taskcluster to make Release events work. > > - Update the docs to talk about creating a Release in Github rather than > > simply pushing a tag. > > > > Because we're going with an HTTP interface that nginx handles for the > > database resets, there's nothing we need to do besides bug 1376331 to suppor > > that. > > Reading over things again, I think we actually may need a command in run.sh > to reset the db. That's pretty scary since it could, in theory, be run for > production. We'll need to find a way to safeguard it... I also realized that the production dump will not contain any permissions, roles, nor required signoffs. I think it's OK (and maybe even a feature) to not have required signoffs and roles in stage, but we'll need something that creates permissions for automation and humans. Perhaps we'll just hardcode some stage-specific inserts to do after the dump is imported.

(In reply to Ben Hearsum (:bhearsum) from comment #2) > I just posted https://github.com/mozilla/balrog/pull/399 which _should_ > contain all of the CI changes needed to do this. > > Past that, I also need to: > - Create the necessary roles in Taskcluster to make Release events work. This is done.

Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/3b4a2fd72fa4ab1f015e8d1d5fabf754a015d5e3 bug 1398237: adjust release process for new stage set-up (#399). r=rail

Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/fea77c82a5542598220e98620cf0eb1ae28fc43c bug 1398237: Add "is signoff required" to UI overall (#408). r=bhearsum

Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/5f609a50e1f6d417186b54998e2423331cf932d2 bug 1398237: Make a command that resets the stage database (#407). r=nthomas

(In reply to Ben Hearsum (:bhearsum) from comment #2) > - Update the docs to talk about creating a Release in Github rather than > simply pushing a tag. I think I've captured this in https://wiki.mozilla.org/index.php?title=Balrog&diff=1182158&oldid=1182125. I've probably got a couple of more tweaks to make after we run through it once or twice, but it's a good starting point.

Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/1e8873594e6c011710c911ad8a4e2aa46cba1db0 bug 1398237: Only make version tags when releasing (#424) * Use explicit tags passed in instead of guessing. * Fix sanity check on tags.

I did another pass on https://wiki.mozilla.org/Balrog to clarify a few things, but I think we're done here now.