[gram-user] GT4 job spec oddness

[Peter G Lane]

On Tue, 2006-05-16 at 14:12 +1000, David Laing wrote:
> Hi all,
> 
> I've been using the GT4.0.2 binary for FC4 on x86 to test the Gridsphere Gridportlets/GT4portlets projects out.  
> 
> There's been a couple of problems that appear to stem from the globus side of things.  The gridportlets builds a job script, which I've copied to a file and tried to submit using the command line tools.  I've been trying to set up the following test:
> 
> http://globus.org/toolkit/docs/4.0/execution/wsgram/user-index.html#s-wsgram-user-specifyingstaging
> 
> The XML that is generated from the portlet is as follows:
> ----------------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <job>
>  <executable>${GLOBUS_USER_HOME}/echo</executable>
>  <argument>This</argument>
>  <argument>is</argument>
>  <argument>a</argument>
>  <argument>test</argument>
>  <directory>${GLOBUS_USER_HOME}</directory>
>  <stdout>${GLOBUS_USER_HOME}/stdout</stdout>
>  <stderr>${GLOBUS_USER_HOME}/stderr</stderr>
>  <count>1</count>
>  <jobType>single</jobType>
>  <fileStageIn>
>      <transfer>
> <sourceUrl>gsiftp://dave-hpc.hpc.jcu.edu.au:2811/bin/echo</sourceUrl>       <destinationUrl>file://${GLOBUS_USER_HOME}/echo</destinationUrl>
>      </transfer>
>  </fileStageIn>
>  <fileStageOut>
>      <transfer>       
> <sourceUrl>file://${GLOBUS_USER_HOME}/stdout</sourceUrl>       <destinationUrl>gsiftp://dave-hpc.hpc.jcu.edu.au:2811/tmp/stdout</destinationUrl>
>      </transfer>
>  </fileStageOut>
> </job>
> ----------------------------------------
> 
> globusrun-ws -submit -f test.xml -S
> 
> Initially we get:
> ----------------------------------------
> globusrun-ws: Error loading rsl
> globus_soap_message_module: Unexpected directory element in message while looking for an end tag
> ----------------------------------------
> 
> The problem goes away if we manually move the directory element above the argument elements.  I don't know if the order is meant to matter in the schema.  There's a simple fix to get the XML generated with the bits in the right order - I'm just unsure if that is necessary.

Yes, the schema uses a sequence which implies an order.

> Anyhow, with that change made to the script (or GridGramRsl2XmlConverter in gridportlets), we get:
> ----------------------------------------
> globusrun-ws: Job failed: Invalid fileStageIn element.
> Host not allowed in file URL "file://${GLOBUS_USER_HOME}/my_echo", but found "${GLOBUS_USER_HOME}".
> ----------------------------------------
> 
> Which can be fixed by adding an extra / to the file urls in the staging directives i.e. file:///${GLOBUS_USER_HOME}/my_echo
> 
> But since ${GLOBUS_USER_HOME} starts with a slash, I would have thought that would be redundant, provided it's getting expanded before it's getting checked.

> I can patch the gridsphere code to add an extra slash when it generates the file urls, but again it seems unnecessary.

I understand, but the service doesn't know ahead of time if there's an
extra slash. For example, you could put ${GLOBUS_USER_NAME} in there
instead which doesn't have a beginning slash. Besides that, without the
third slash it is technically an invalid URL. The third slash is not
part of the path according to the URL spec, so really the problem is
that the substitution variable contains an extra slash when it
shouldn't. You might use the variable somewhere else, though, so the
beginning slash can't be left out. The URL will eventually be normalized
as well, so the fourth slash will be removed.

> I'm not sure if I'm pointing out bugs or my own misunderstandings of how things work.  Both behaviours are at the very least counter intuitive for me, and both can be dealt with via some nasty hack-like behaviour at the gridportlets end if necessary.

Using xsd:all in the job description schema instead of xsd:sequence
might be a little more intuitive, but then there's a limit in the
maxOccurs attribute of elements to either 0 or 1. It's impossible to
differentiate between those elements that should only be allowed once
(i.e. executable) and those that can be listed many times (i.e.
argument). Since cardinality is more important to us than allowing
random ordering of elements, we're deliberately sticking with
xsd:sequence.

As for the file URL, this is a standards issue. As I said, without the
third slash the file URL is not correct according to the spec. I'm sorry
it's not intuitive to you, but that's the way it is.

Peter

> Just thought I'd make mention of the observations in case they turn out to be important/useful. 
> 
> Cheers
> 
> Dave
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3720 bytes
Desc: not available
URL: <http://lists.globus.org/pipermail/gram-user/attachments/20060516/943b7e4d/attachment.bin>