[Swift-devel] sites.xml

[Ben Clifford]

In bug 32, Mihael commented:

> The handshake failure is caused by the fact that the url is not valid. 
> GT4 does not use /jobmanager-xyz in the URL, and therefore the one you 
> use is trying to access a non-WSRF URL in the container (which causes 
> the GSI handshake to fail, because it gets some 404 page back).
                                                                                
> This brings up a problem. The GT2 style job manager specification is 
> clearly not portable. In cog, resources (aka services) have an 
> additional jobManager attribute which can be used to portably specify 
> job managers, and the providers take care of translating that into 
> whatever the implementation requires.  However, this would require a 
> modification on the structure of the sites.xml file. I think it should 
> be OK to add a jobManager attribute, while still allowing the 
> /jobmanager-xyz thing for classic GRAM resources, but not for WS-GRAM.

There's no real backwards compatibility reason to stick with anything like 
the sites.xml format that we have now. Some of the stuff is out of place 
in there already and eventually it might warrant a big tidyup.

Also, WS-GRAM (at least in theory) doesn't use URLs with a job-manager - 
it uses an opaque EPR in the form of an XML blob. Alas, these are so 
appallingly unusable that for the most part people have settled on rigid 
structure for the EPRs when that rigid structure shouldn't be there. Roll 
on the day when someone actually fixes that. Come back GT3. All is 
forgiven. 

VDS already has a way to specify GRAM4 resources but I can't remember. 
Maybe its similar to the one used by condor - they use this format for the 
jobmanager string (it wrapped on paste - newlines are spaces):

grid_resource = gt4 
 [https://]IPaddress[:port][/wsrf/services/ManagedJobFactoryService] 
 scheduler-string

(according to 
http://www.cs.wisc.edu/condor/manual/v6.8/5_3Grid_Universe.html#SECTION00632400000000000000)

--