I think this is nearly it. Thank you for all your comments and contributions. Further changes to the word document need to come in very very soon! The wiki page - www.ogf.org/HPCBasicProfile<http://www.ogf.org/HPCBasicProfile> - can of course be continuously updated. Steven
All, Service instance 1. The first GridSAM instance(the one with '/ForkDRM/' in the URL) I made available a few days ago will be executing jobs through forked processes on the same host the service is running. This instance does not support the HPCP Credentials extension and while it does support DataStaging extension the JSDL provided does not make any use of it. Earlier this evening, someone tried testing against this instance with a JSDL having <StagingSchedule> element in it. The job failed as the parser recognised this element was not part of the JSDL schema. To work around this - enter a dummy namespace for this element so the parser accepts it as a JSDL schema extension <StagingSchedule xmlns='http://dummy/namespace'> - or better yet - use only the JSDL I've provided. **!!**To help with debugging - you might want to put a unique value in the JSDL's <ProjectName> element, such as your name for example. You can view the output of your successfully executed job by pointing a web browser to "https://gridsam.lesc.doc.ic.ac.uk:18443/sc07demo/spool" Service instance 2. I've added a link on the wiki for one more GridSAM service instance. The service(the one with '/GlobusDRM/' in the URL), through its GlobusDRM connector, will be submitting jobs to a Globus portal to the UK National Grid Service resources. This instance supports DataStaging and Credentials extensions. The new JSDL provided specifies 3 different sets of credentials: * one required to submit/execute the job to/on the NGS resources. * one required to stage-in/out files from/to an UVA FTP server. * one required to stage-out/ files to an Imperial SFTP server. **!!!** NOTE **!!!** Since the same user accounts will be used for staging-out files, MAKE SURE you change the name of the output(staged-out) files in the JSDL before you submit the job - example: from: "sftp://gridsam.lesc.doc.ic.ac.uk/sftp/out/enter_file_name_here.out" to: "sftp://gridsam.lesc.doc.ic.ac.uk/sftp/out/vesso.out" Otherwise we will be overwriting each other's job submission results. You can view the output files staged-out to the Imperial's SFTP server by pointing a web browser to "https://gridsam.lesc.doc.ic.ac.uk:18443/sc07demo/sftp/out" GridSAM Client tests with other services. So far I have successfully tested against: * UNICORE service - completely * UVA - partial success * Platform - partial success --Vesso
Hi all, I should have mentioned that the GridSAM service installations, while capable of using x509 certificates, are not configured to do so for this demo. Therefore, all clients used to send request to my service must be configured to include the WS-Security UsernameToken type headers in the soap message. --Vesso P.S. I have messages in the log files indicating that someone had tried to test the services using an invalid(missing HPCProfileApplication element) JSDL. Pl., use the JSDLs I have posted on the wiki, so that your tests do not fail for "...Invalid JSDL doc..." - type reasons. --Vesso vesso@doc.ic.ac.uk wrote:
All,
Service instance 1. The first GridSAM instance(the one with '/ForkDRM/' in the URL) I made available a few days ago will be executing jobs through forked processes on the same host the service is running. This instance does not support the HPCP Credentials extension and while it does support DataStaging extension the JSDL provided does not make any use of it. Earlier this evening, someone tried testing against this instance with a JSDL having <StagingSchedule> element in it. The job failed as the parser recognised this element was not part of the JSDL schema. To work around this - enter a dummy namespace for this element so the parser accepts it as a JSDL schema extension <StagingSchedule xmlns='http://dummy/namespace'> - or better yet - use only the JSDL I've provided. **!!**To help with debugging - you might want to put a unique value in the JSDL's <ProjectName> element, such as your name for example.
You can view the output of your successfully executed job by pointing a web browser to "https://gridsam.lesc.doc.ic.ac.uk:18443/sc07demo/spool"
Service instance 2. I've added a link on the wiki for one more GridSAM service instance. The service(the one with '/GlobusDRM/' in the URL), through its GlobusDRM connector, will be submitting jobs to a Globus portal to the UK National Grid Service resources. This instance supports DataStaging and Credentials extensions. The new JSDL provided specifies 3 different sets of credentials: * one required to submit/execute the job to/on the NGS resources. * one required to stage-in/out files from/to an UVA FTP server. * one required to stage-out/ files to an Imperial SFTP server. **!!!** NOTE **!!!** Since the same user accounts will be used for staging-out files, MAKE SURE you change the name of the output(staged-out) files in the JSDL before you submit the job - example: from: "sftp://gridsam.lesc.doc.ic.ac.uk/sftp/out/enter_file_name_here.out" to: "sftp://gridsam.lesc.doc.ic.ac.uk/sftp/out/vesso.out" Otherwise we will be overwriting each other's job submission results.
You can view the output files staged-out to the Imperial's SFTP server by pointing a web browser to "https://gridsam.lesc.doc.ic.ac.uk:18443/sc07demo/sftp/out"
GridSAM Client tests with other services. So far I have successfully tested against: * UNICORE service - completely * UVA - partial success * Platform - partial success
--Vesso
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
participants (3)
-
Steven Newhouse -
Vesso Novov -
vesso＠doc.ic.ac.uk