[Swift-devel] fun with osg

[Ben Clifford]

I played some with Mats Rynge at RENCI today.

He modified some code he already had to output sites.xml based on the OSG 
ReSS information system.

This made it straightforward to submit jobs to sites that are in OSGEDU 
(the only OSG VO that I am a member of) running executables that are 
already on the system $PATH.

However, of the 13 sites advertising that they support OSG EDU, only two 
are actually able to run Swift jobs this afternoon.

I just got setup to submit jobs to the OSG Engagement VO; this changes the 
range of sites available, but also opens up some more opportunity for 
narrowing down the range of available sites as the Engagement VO has a 
richer set of site availability information that can be used to construct 
a more-likely-to-work sites.xml file.

Of the two working-and-published OSGEDU sites, I also tried running with 
coasters; that failed dismally on both - in the case of one site, the fork 
job manager was the ever-more-common ManagedFork jobmanager, which appears 
unable to be able to execute the head jobs. The other site ran the head 
job but worker nodes could not communicate properly with that. so frrrr.

There also remains the problem of application location and deployment; in 
my playing today I used default $PATH method of finding my test executable 
(touch) - this is still hard, though I have some other notes to write 
about that elsewhere.

Replication seems to do a good job with failing sites, although not a 
completely perfect job. One site takes jobs to the karajan Active state 
and then stays there forever. Replication, as presently implemented, 
doesn't cope with that.

So nothing particularly new - OSG as usual...

--