[Debian Wiki] Update of "BOINC/ServerGuide/WrapperApp" by SteffenMoeller

Debian Wiki debian-www at lists.debian.org
Sun Jul 24 13:07:56 UTC 2011


Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "BOINC/ServerGuide/WrapperApp" page has been changed by SteffenMoeller:
http://wiki.debian.org/BOINC/ServerGuide/WrapperApp?action=diff&rev1=7&rev2=8

Comment:
series of smallish changes to improve readability.

  
  = Wrapper Application =
  
- BOINC provides a wrapper app to use normal binaries in a BOINC environment. The sources are shipped with BOINC, and is available in debian through boinc-app-examples package.
+ BOINC provides a wrapper app to use normal binaries in a BOINC environment. The sources are shipped with BOINC, and is available in Debian through the boinc-app-examples package.
  
  In short, The wrapper system works like this, 
   * BOINC executes the wrapper binary, which BOINC considers as a multi-file application.
@@ -22, +22 @@

  
  == Deployment ==
  
- '' In the experiment branch, Multifile project management of BOINC has changed a lot. Please note that the steps illustrated here are for the debian boinc-server-maker package or more specifically, [[ http://boinc.berkeley.edu/svn/branches/server_stable | sever_stable]] branch of BOINC. ''
+ '' In the experiment branch, multifile project management of BOINC has changed a lot. Please note that the steps illustrated here are for the debian boinc-server-maker package or more specifically, [[ http://boinc.berkeley.edu/svn/branches/server_stable | sever_stable]] branch of BOINC. ''
  
  The deployment is little bit tricky, as of now, cant just apt-get them. (well, we are working on it.).
  
- The wrapper deployment is explained here as cases, select one with your requirements and follow. The documents here are a follow up from AppDeployment page. It assumes that you are familiar with the normal app deployment using debian and BOINC.
+ The wrapper deployment is explained here as cases, select one with your requirements and follow. The documents here are a follow up from [[BOINC/ServerGuide/AppDeployment]] page. It assumes that you are familiar with the normal app deployment using Debian and BOINC.
  
  === Obtain the binaries ===
  
- Use the fetch_example_applications script provided with the boinc-server-maker package to obtain the binaries for the wrapper applications, copy them to the app folder of the project root. Since this is a multifile project, the directory hirearchies are important. The binaries should be arranged as follwing structure.
+ Use the fetch_example_applications script provided with the boinc-server-maker package to obtain the binaries for the wrapper applications, copy them to the app folder of the project root. Since this is a multifile project, the directory hierarchies are important. The binaries should be arranged as following structure.
  
- In multi file applications, The files are put in a subdirectory of name appname_version_fullplatformname.
+ In multi file applications, The files are put in a sub-directory of name ''appname''_''version''_''fullplatformname''.
  
  {{{
  apps/
@@ -52, +52 @@

  }}}
  
  
- 
  === Configuring the wrapper ===
- The wrapper binary on running checks for a job description file named ''job.xml'', which is used to inform the wrapper about the actual bianry and the arguments to pass. This file has to be present in project root.
+ The wrapper binary upon invocation checks for a job description file named ''job.xml'', which is used to inform the wrapper about the actual binary to execute and its command line arguments to pass. This file has to be present in project root.
  
  Sample job.xml
  {{{
@@ -69, +68 @@

  </job_desc>
  }}}
  
+ == Simple script with no input ==
+ The example script used in this section counts from 0 to a number specified as command line argument, and outputs as ''out'': {{{
+ cat <<EOSCRIPT > count 
+ #!/bin/bash
+ seq $1 > out
+ EOSCRIPT
+ }}}
  
+ The script will be executed directly, so it better becomes executable: {{{
+ chmod +x count
- 
- == Simple script with no input ==
- The example script used in this section counts from 0 to a number specified as command line argument, and outputs as ''out''.
- 
- {{{
- user at host $ cat count 
- #!/bin/bash
- seq $1 >> out
  }}}
  
  === Create directory structures ===
- The job description file for this script will look like this,
+ The job description file for this script will look like this: {{{
- 
- {{{
  <job_desc>
      <task>
          <application>count</application>
@@ -92, +90 @@

  </job_desc>
  }}}
  
- As mentioned the payload binary/script has to be copied to the subdirectory for each platform. Since the script doesnt have any platform dependencies, we do
+ As mentioned above, the payload binary/script has to be copied to the sub-directory for each platform. Since the script can be the same for every platform (it is just text), we do plain copies: {{{
+ cd $projectroot
- 
- {{{
- user at host $cd $projectroot
- user at host $for p in apps/wrapper/*/
+ for p in apps/wrapper/*/
  do
- cp path/to/count path/to/count.sig path/to/job.xml path/to/job.xml.sig $p
+   cp path/to/count path/to/count.sig path/to/job.xml path/to/job.xml.sig $p
  done
  }}} 
  
- Now the app directory should be
+ Now, the app directory should look like ... except for the .sig files, which are added only later by the automated signing by ''bin/update_versions'':
  {{{
  apps/
  `-- wrapper
@@ -127, +123 @@

          |-- count.sig
          |-- wrapper_6.12_x86_64-pc-linux-gnu
          `-- wrapper_6.12_x86_64-pc-linux-gnu.sig
- 
  }}}
  
- Use xadd and update_versions to put the app to database.
+ Use ''bin/xadd'' and ''bin/update_versions'' to put the app to database: {{{
- 
- The executable permission for the script should be set.
+ to be added, present the option for the automate signing (sm)
+ }}}
  
  === Workunit ===
- The application doesnt have an input, and do a trivial small computaion. A sample workunit template for the script should look like
  
- {{{
+ ==== Template files ====
+ 
+ The application does not have an input, and dos a trivial small computation. A sample workunit template for the script should look like {{{
  <workunit>
      <rsc_fpops_bound>1e12</rsc_fpops_bound>
      <rsc_fpops_est>1e14</rsc_fpops_est>
  </workunit>
  }}}
  
+ The ''rsc_fpop'' directives are used to define computational size parameters, expressed as number of FLOPS needed by the program. Our ''count'' produces a file named ''out'' as output, which should be transported back, the result template will be {{{
- rsc_fpop directives are used to define computaional size parameters, expressed as number of FLOPS needed by the program.
- 
- The count produces a file named ''out'' as output, which should be transported back, the result template will be
- {{{
  <file_info>
      <name><OUTFILE_0/></name>
      <generated_locally/>
@@ -164, +157 @@

  </result>
  }}}
  
+ ==== Work units added to system ====
+ 
  Finally create work, 
  {{{
- user at host $cd $projectroot
- user at host $./bin/create_work --appname wrapper --wu_name wrapper_test --wu_template /path/to/wu/template --result_template /path/to/result/template
+ cd $projectroot
+ ./bin/create_work --appname wrapper \
+                   --wu_name wrapper_test \
+                   --wu_template /path/to/wu/template \
+                   --result_template /path/to/result/template
  }}}
+ 
+ This effort has now added a single job to the system. For adding multiple jobs with different input files, do as follows.
+ 
+ TBA
+ 
  == See Also ==
   * [[http://boinc.berkeley.edu/trac/wiki/WrapperApp|upstream documentation]]
   * [[http://code.google.com/p/boincvm/wiki/VMWrapper|Python based Wrapper exploiting BOINC legacy apps wrapper method.]]



More information about the pkg-boinc-commits mailing list