XgridDRMAA ObjC interface
I put together some headers for the Objective-C DRMAA interface. They follow the Java bindings pretty closely, with some name changes to match Cocoa naming conventions better, plus the use of NSError instead of exceptions. They also will reuse the constants defined in the C headers where relevant.
The one most glaring DRMAA requirement I’ve noticed missing from Xgrid is the ability to change the working directory before running the command. For missing things like this, I think it will be best to simply leave the implementation incomplete, tell Apple, and hope that the feature appears in the next release. This won’t hinder my ability to write GridSweeper as a pure-DRMAA app, so I can live without it for now.
Browse the code here.
June 5th, 2006 at 9:06 pm
You are right. I never really used the ‘environment’ key, but this does not work:
{
jobSpecification = {
applicationIdentifier = “com.apple.xgrid.cli”;
inputFiles = {};
name = “/bin/sh”;
submissionIdentifier = abc;
taskSpecifications = {
0 = {
environment = { TEST = “testing”; PWD = “/bin”; };
command = “/bin/sh”;
arguments = (”-c”, “/bin/echo PWD=$PWD; /bin/echo TEST=$TEST; ls”);
};
};
};
}
Some security issue?? (this is always a good excuse!)
June 6th, 2006 at 12:43 pm
Security’s not an answer here, because you can of course change the working directory from the executable. Or rather, in the case of non-SSO setups running as nobody, you can’t! I suspect the answer is that they didn’t think it would be necessary, since the executable can do it anyway. Unfortunately, that means the full DRMAA API can’t be supported fully by mapping things directly from DRMAA to Xgrid.
I could, however, decide to ship off a small executable or shell script with each DRMAA job that wrapped the “real” job, first changing directories (and failing if the privileges aren’t there).
That little executable could also collect better resource usage information, something that Xgrid doesn’t do natively…my, this is sounding like a good idea!
June 10th, 2006 at 9:46 pm
It is a good idea to wrap the executable. I was thinking of doing that too for automatic caching of files and executables. Also, wrapping helps to catch more error and have more useful error messages.
Yes, definitely lots of good things!