ReleaseEngineering/BuildAPI: Difference between revisions

← Older edit

ReleaseEngineering/BuildAPI (view source)

Revision as of 03:17, 9 February 2017

1,748 bytes added , 9 February 2017

m

→‎BuildAPI: formatting

NThomas

Confirmed users

4,293

edits

@@ Line 1: / Line 1: @@
-{{Release Engineering How To|Deploy BuildAPI changes}}
+{{Release Engineering How To|BuildAPI}}
 = Overview =
 The BuildAPI is a Pylons project used by RelEng to surface information collected from two databases updated through our buildbot masters as they run jobs.
@@ Line 152: / Line 152: @@
 === BuildAPI ===
-BuildAPI updates are handled like any other webapp, through pushes. See [[ReleaseEngineering/How_To/Update_BuildAPI]] for a bit more detail.
+BuildAPI updates are handled like any other webapp, through pushes. See also [[ReleaseEngineering/How_To/Update_BuildAPI]]
+The steps are roughly as follows, from the base directory of buildapi:
+* Push new version of BuildAPI to HG
+** Edit setup.py to show the updated version (eg version='0.3.0' becomes version='0.3.1')
+* Build a new sdist tarball of BuildAPI, using normal python techniques, and upload it to the our pypi repository on relengwebadm.private.scl3.mozilla.com.
+** Tarballs can be seen here: http://pypi.pub.build.mozilla.org/pub/
+  python setup.py sdist
+  VERSION=0.3.1
+  scp dist/buildapi-${VERSION}.tar.gz relengwebadm.private.scl3.mozilla.com:
+  ssh relengwebadm.private.scl3.mozilla.com
+  VERSION=0.3.1
+  sudo mv buildapi-${VERSION}.tar.gz /mnt/netapp/relengweb/pypi/pub/
+  sudo chmod 664 /mnt/netapp/relengweb/pypi/pub/buildapi-${VERSION}.tar.gz
+* Deploy to the webheads, reusing the relengwebadm ssh session from above
+  sudo su -
+  cd /data/releng/src/buildapi   # or for staging /data/releng-stage/src/buildapi
+  ./update 0.3.1
 === Selfserve Agent ===
@@ Line 180: / Line 199: @@
 === report crontask ===
-There's a crontask on [https://mana.mozilla.org/wiki/display/websites/Releng+Cluster relengwebadm] that runs every minute to generate the builds-4hr.js file.  If this crontask gets "hung", it will prevent updates from occuring.  This can happen due to DB connection issues, or bad data in the DB.  In these cases, killing the hung crontask is the appropriate fix.
+There's a crontask on [https://mana.mozilla.org/wiki/display/websites/Releng+Cluster relengwebadm] that runs every minute to generate the builds-4hr.js file.  If this crontask gets "hung", it will prevent updates from occuring.  This can happen due to DB connection issues, or bad data in the DB.  In these cases, killing the hung crontask is the appropriate fix. There may be a stale lockfile that need removing under /var/lock/buildapi too.
 However, the crontask takes about 15 minutes to run on a cold cache.  So if its cache (memcached) has gone cold, then killing it before 15 minutes have elapsed is only delaying the failure.
-You can also read [https://bugzilla.mozilla.org/show_bug.cgi?id=1005342#c6 this comment].
+From [https://bugzilla.mozilla.org/show_bug.cgi?id=1005342#c6 bug 1005342]:
+{| class="wikitable"
+|-
+| ''Dustin J. Mitchell [:dustin] 2014-05-02 16:18:14 PDT''
+I looked at 4:01 pacific, and saw that builds-4hr.js.gz had last been generated at 2:47.  This is generated by a crontab that runs every minute, and makes a lot of heavy queries against the DB.  On a good day with a cold cache, it's about 15 minutes.  With a hot cache it can finish comfortably in one minute.  It would seem that Matt's heavy query caused the builds-4hr.js.gz queries to go slowly, and thus caused the file's generation to fall behind.
+I found the crontask, appropriately dated 2:47, and killed it.  Cron started a new one up on the minute, and that completed in something like 45s.
+I don't know why the original job didn't complete soon after mpressman cancelled his query.
+|}
 = Staging =