Changes between Version 12 and Version 13 of NuWa_Slave

Timestamp:

09/09/10 21:24:26 (15 years ago)

Author:

blyth (IP: 140.112.102.77)

Comment:

tack on the email

NuWa_Slave

@@ -428 +428 @@
  
 
-
-
-
-
+= ''dybbin'' Approach Under Discussion =
+
+
+  * '''dybbin''' allows a NuWa installation to be copied to another location
+
+== email to David, Jiajie ==
+
+{{{
+ I like the elimination of a separate build in this dybbin
+ approach however I see several problems with usage of update builds
+ and externally imposed cron dybbin,  my suggested solutions :
+
+  * Update build
+       Are promoting usage of an update build,
+       which is prone to breakage on data model changes and is generally
+       the subject of negative prejudice.
+
+       Can eliminate this issue by making the dybinst command used by the slave
+          "./dybinst -c trunk project dybgaudi"
+       do a refresh when data model changes are detected.
+
+ Enforcing external cron cut-off times introduces issues (and leads to
+ complicated workarounds) :
+
+   * A build can be in-progress at cron dybbin time or the last build
+     can be broken ... meaning there is no valid build to copy.
+
+   * Uncoordinated between sites, the prevalent build at dybbin time
+     may differ between sites according to speed/breakage differences between slaves.
+
+ To avoid these issues (and complicated workarounds),
+ I suggest not to impose an external cron job but rather to to add a
+ final step to the dybinst slave build that (if the tests succeeded)
+ performs a dybbin copy "installation" into a directory named after the revision.
+ And performs purging to remove excess revision directories.
+
+One possible problem with this scheme is that our 'daily' might not match the
+'daily' elsewhere, but I think that could be handled, perhaps by having the master
+define the revision number corresponding to the current 'daily'.
+
+
+ Concerning coordination between slaves (although I have implemented
+ such a system in the ad-hoc daily.bash) I think supporting and explaining
+ complex procedures for this is not worth the effort/confusion.
+
+ Simply referring to builds by their real name : '''the revision number'''
+ and not the date eliminates the issue and benefits from direct
+ correspondence between the state of builds reported in the web interface
+ (including the timeline).
+
+ Users will want to use a build after a particular
+ feature has been added (or bug removed) ... thus they should
+ know the minimum revision they want.
+ They can then look for a corresponding build that the slave on
+ their cluster succeeded to build at :
+    http://dayabay.ihep.ac.cn/tracs/dybsvn/build/dybinst
+
+Yours, Simon
+}}}
+
+
+