Dear Wiki user, You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.
The "DebianMed-Taverna-20110130" page has been changed by Hajo Krabbenhöft: http://wiki.debian.org/DebianMed-Taverna-20110130?action=diff&rev1=5&rev2=6 There is currently some limited ways of specifying what needs to be on the machine where a tool will be run, and also how to check if the tool can be run there. Need to look at more general ways of specifying this. + For all xRSL-compatible grids, we can just use the RE-lines we currently use. + + For BOINC, we need a mapping from RE to tar files, which we need to submit to BOINC alongside our data & job description. + + For Amazon/Eucalyptus/Rackspace/VMWare, the user needs to prepare VM images beforehand. We therefore require him to create a list of URLs to his VM images and tag each VM image with the REs he installed inside the VM. + + So our problem child is local (on linux) and SSH invocation. For those invocation mechanisms, we include RE blocks inside the usecase.xml: + + <RE name="APPS/JAVA-1.6.1"> + <test local="test -x /usr/bin/java" /> + <hint package="sun-java6-jdk"> + You're missing Java, please install. + </hint> + </RE> + + We can then automatically suggest "apt-get install sun-java6-jdk" on debian systems, otherwise we show the user "You're missing Java, please install.". + + The benefit of this over having a <test ...> in every use case is that we only have to write the test once for all use cases using the same tools. + == Sensible handling of data == Want to minimize the transfer of data. So data stays, where possible, with the tools that will use it. Also, tools are invoked where the data is. _______________________________________________ debian-med-commit mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-med-commit
