ReleaseEngineering/How To/Reset the Try Server: Difference between revisions

Jump to navigation Jump to search

ReleaseEngineering/How To/Reset the Try Server (view source)

Revision as of 19:16, 23 January 2014

1,293 bytes removed ,  23 January 2014
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
{{Release Engineering How To|Reset the Try Server}}
{{Release Engineering How To|Reset the Try Server}}
Due to increased usage on tryserver, this is something we need to do approx once a month. This can typically be done in 30-60minutes.


* joduinn can grab this information through buildapi now. <strike>make sure joduinn has extracted all the logs he needs for blogposts. Its nice, but not required, to do this repo reset at the end of the calendar month, as it makes blogpost work easier.</strike>
The Try server [http://hg.mozilla.org/try repo] needs to be reset periodically (measured in weeks and months). This is due to Mercurial slowing down over time with the usage pattern that Try places on it.
* RelEng to post downtime notices to dev.planning, and mark the [http://tinderbox.mozilla.org/showbuilds.cgi?tree=Try TryServer closed].
** Note this does *not* touch any production build/test/talos machines, so does *not* require closing mozilla-central, or any other tree.
* File IT bug to
** delete [http://hg.mozilla.org/try the try server hg repo]
*** Before you do this, save the hgrc (/repo/hg/mozilla/try/hgrc). You'll have to put the hooks back and this will help.
***rm -rf /repo/hg/mozilla/try
**** (Alternatively, move the try repo away so you have a backup till everything is verified as working)
** create a fresh new hg repo cloned from mozilla-central
***su - hg
***cd /repo/hg/mozilla
***hg clone -U mozilla-central try
** create an empty pushlog db.
***su - hg
***cp /repo/hg/mozilla/mozilla-central/.hg/pushlog2.db /repo/hg/mozilla/try/.hg/pushlog2.db
***chown hg:scm_level_1 /repo/hg/mozilla/try/.hg/pushlog2.db
***chmod g+w /repo/hg/mozilla/try/.hg/pushlog2.db
***cd /repo/hg/mozilla/try/.hg/
***sqlite3 pushlog2.db
***sqlite> delete from changesets;
***sqlite> delete from pushlog;
***sqlite> .exit
**Reset perms on the repo.
***Become the root user on the machine.
***cd /repo/hg/mozilla/
***chown -R hg:hg_mozilla try
**Reset the varnish cache
***Login to dm-vcview04
***unmount /mnt/tmp_try && mount /mnt/tmp_try
***cp -a /repo/hg/mozilla/try /mnt/tmp_try/
***cp -f /repo/hg/scripts/try_clone.hgrc /mnt/tmp_try/try/.hg/hgrc
***chown -R hg:scm_level_1 /mnt/tmp_try/try
***service httpd restart
***service varnish restart
* RelEng to remove message from tinderbox server.  


[RelEng no longer needs to push 1.9.1 and 1.9.2 to try, since we don't support those branches; <strike>and doesn't need to reconfig any masters to get the hg polling working again.</strike>]
Mozilla IT have scripted the Try repo reset. The location of the script is TBD (:fubar is finding a place for it).


==== Try Hg Poller state ====
Historically, Try was reset once developers grew frustrated at the slowdown of Try pushes and TBPL responsiveness (TBPL relies on the Try repo pushlog).  The reset would need to be approved at the CAB (change advistory board) meeting and communicated to developers (dev-gaia dev-gaia@lists.mozilla.org, dev-b2g@lists.mozilla.org, dev-planning@lists.mozilla.org, dev-platform@lists.mozilla.org, dev-tree-management@lists.mozilla.org) at least the day before the reset (unless critical).


It turns out that sometimes when the repository is reset the hg poller gets into a bad state. Reconfiguring the scheduler master fixes the problem and is a quick procedure
Try reset machanics:
 
* RelEng closes Try (mention bug#)
* IT runs Try reset script
* RelEng reconfig's the buildbot schedulers (to reset the hg poller state)
* RelEng reopens Try
 
Going forward (after January 23, 2014), Try will be reset at each pre-planned tree closing window (TCW).
Jhopkins
Confirmed users
1,018

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/903972"

Navigation menu