MozillaWiki

ReferencePlatforms/How To/Setup a New Reference Platform: Difference between revisions

Page Discussion

ReferencePlatforms/How To/Setup a New Reference Platform (view source)

Revision as of 14:30, 25 September 2015

985 bytes removed ,  25 September 2015
→‎Open bugs for graph server changes
 
(11 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Congratulations.  You have been chosen to setup a new reference platform.  Armen summarized this journey as "It will be difficult".  In addition to testing the new image on the test or build machines, there are several other steps that must be taken to ensure that our build infrastructure is read to work with the new platform and the associated slaves.   
Congratulations.  You have been chosen to setup a new reference platform.  Armen summarized this journey as "It will be difficult".  In addition to testing the new image on the test or build machines, there are several other steps that must be taken to ensure that our build infrastructure is read to work with the new platform and the associated slaves.   
There are several tasks that you can do ahead of time to make it easier noted in the checklist below. Many of these involve IT, so open bugs accordingly.
There are several tasks that you can do ahead of time to make it easier noted in the checklist below. Many of these involve IT, so open bugs accordingly.
{{Release Engineering How To|Setup a New Reference Platform}}


== Do you need a new master? ==
== Do you need a new master? ==
Line 21: Line 23:


This is a example {{bug|783455}}.  The  buildmaster-production.pp  (puppet-manifests) needs to have the new masters added to the nodes so you can puppetize the new masters.  The productionmasters.json (tools) needs to have the new masters listed.  I initially set them to disabled, they will be enabled when we are ready for production.  Before the reconfig to enable the new master occurs, you should add ssh keys and an updated authorized_keys file to the master.  Once the reconfig is complete, you'll need to start the new master.
This is a example {{bug|783455}}.  The  buildmaster-production.pp  (puppet-manifests) needs to have the new masters added to the nodes so you can puppetize the new masters.  The productionmasters.json (tools) needs to have the new masters listed.  I initially set them to disabled, they will be enabled when we are ready for production.  Before the reconfig to enable the new master occurs, you should add ssh keys and an updated authorized_keys file to the master.  Once the reconfig is complete, you'll need to start the new master.
=== Are you able to send mail to the tinderbox server from the new master? ===
{{bug|717808}} is an example.  Tested this tonight from bm37, think it works
<pre>
Aug 19 16:47:06 buildbot-master38 sendmail[17861]: q7JNl5wW017859: to=<dm-mail01@tinderbox.mozilla.org>, ctladdr=<root@buildbot-master38.srv.releng.scl3.mozilla.com> (0/0), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=120434, relay=mx1.corp.phx1.mozilla.com. [63.245.216.69], dsn=5.1.1, stat=User unknown
Aug 19 16:47:06 buildbot-master38 sendmail[17861]: q7JNl5wW017859: q7JNl6wW017861: DSN: User unknown
Aug 19 16:47:06 buildbot-master38 sendmail[17861]: q7JNl6wW017861: to=<root@buildbot-master38.srv.releng.scl3.mozilla.com>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=31748, dsn=2.0.0, stat=Sent
</pre>


== Open a bug for buildbot and puppet changes ==
== Open a bug for buildbot and puppet changes ==
Line 43: Line 34:


* testing machines and each type of build need graph server changes
* testing machines and each type of build need graph server changes
** You can insert graph changes by logging to slavealloc
** graph server work needs to be run on staging (graphs_mozilla_org_new) and production (graphs_stage2_prod) graph server
** need to land changes to 'sql/data.sql' on the default branch of http://hg.mozilla.org/graphs (to match your inserts).
** need to land changes to 'sql/data.sql' on the default branch of http://hg.mozilla.org/graphs (to match your inserts).
** If this is a new build platform, make sure that graph server knows about the build platform
** If this is a new build platform, make sure that graph server knows about the build platform
*** insert a machine name like %OS%_%branch% (e.g. "WINNT_5.2_mozilla-central" and "WINNT_5.2_mozilla-central_leak_test")
*** insert a machine name like %OS%_%branch% (e.g. "WINNT_5.2_mozilla-central" and "WINNT_5.2_mozilla-central_leak_test")


For example:
We don't have access to update the graph server anymore.  You need to open a bug with the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Data%20%26%20BI%20Services%20Team&component=Database%20Operations database operations team]  to add them. This is an example {{bug||1131072}} of such a request.
<pre>
tart transaction;
insert into os_list values (null, "WINNT 6.2 x64");
SET @lastid = LAST_INSERT_ID();
insert into machines values (null, @lastid, 0, "2.67", "t-w864-ix-001", 1, unix_timestamp());
insert into machines values (null, @lastid, 0, "2.67", "t-w864-ix-002", 1, unix_timestamp());
commit;
</pre>


NOTE: If you inadvertently add an incorrect entry to the graph database, it is best to remove that entry so it doesn't appear as an option on this page, for example: http://graphs.mozilla.org/graph.html
NOTE: If you inadvertently add an incorrect entry to the graph database, it is best to remove that entry so it doesn't appear as an option on this page, for example: http://graphs.mozilla.org/graph.html


== Open a bug for tbpl changes ==
== Open a bug for Treeherder changes ==
* TBPL needs to be patched to support the new platform (see {{bug|782826}} for an example of this change). Please file a bug [https://bugzilla.mozilla.org/enter_bug.cgi?&component=Tinderboxpushlog&product=Webtools here] as soon as possible once the buildernames are known, to avoid delays - since TBPL pushes to production require IT intervention, in addition to the usual patch+review+staging turnaround time.
* Treeherder needs to be updated to support the new platform. Please file a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree+Management&component=Treeherder%3A+Data+Ingestion here] as soon as possible once the buildernames are known, to avoid delays - since unlike TBPL, Treeherder needs regex support prior to the jobs going live, since they are categorised as part of ingestion & not just in the UI layer.


== Open a bug for builfaster changes ==
== Open a bug for buildfaster changes ==
As easy as this ([https://hg.mozilla.org/build/braindump/file/default/reports/buildfaster_report.py buildfaster_report.py]):
As easy as this ([https://hg.mozilla.org/build/braindump/file/default/reports/buildfaster_report.py buildfaster_report.py]):
<pre>
<pre>
Line 71: Line 52:
         ]
         ]
</pre>
</pre>
== Slave health ==
https://hg.mozilla.org/build/tools/rev/5dbaa5080bcd
https://hg.mozilla.org/users/coop_mozilla.com/slave_health/rev/f3eda2cc7d72
https://hg.mozilla.org/users/coop_mozilla.com/slave_health/rev/128bcd9c0e58


== Disable tests on branches where this platform isn't needed ==
== Disable tests on branches where this platform isn't needed ==
Line 131: Line 117:


https://hg.mozilla.org/build/braindump/file/ceaecd3c5b4f/reports/buildfaster_report.py#l73
https://hg.mozilla.org/build/braindump/file/ceaecd3c5b4f/reports/buildfaster_report.py#l73
=== Kittenherder ===
Add support for the new build slave type to kittenherder so it can be auto-rebooted by kittenherder if/when needed.  See {{bug|874957}} for an example, and add a crontab entry on buildduty@cruncher similar to the following:
38    */6  *  *    *  /home/buildduty/production/run_kittenherder.sh tegra


=== BuildAPI ===
=== BuildAPI ===
See https://bug770579.bugzilla.mozilla.org/attachment.cgi?id=747452
See https://bug770579.bugzilla.mozilla.org/attachment.cgi?id=747452
=== Slave health ===
TBD
Kmoir
Confirmed users
1,989

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/665810...1097614"