[jsdl-wg] Re: [ogsa-hpcp-wg] Minutes for OGSA HPC Profile telecon (Aug 18 2006)

[Andreas Savva]

A few comments inline, just in case I can't make the call.

Donal K. Fellows wrote:
> Andreas Savva wrote:
>> I've had a look through the document; here are some comments:
> 
> I'm answering these as I understand them. Points I don't answer are ones
> where I'd just be agreeing with Andreas. :-)
> 
>> 2. Executable is defined as a mandatory element in the same way as in
>> the JSDL PosixApplication. Given the discussions we've had in the
>> context of the EMS Scenarios this should probably be optional (0-1)
>> since the location may not be known until deployment is finished. (This
>> isn't an issue for the HPC profile.)
> 
> Perhaps the right thing to do would be to leave it optional in this spec
> and then profile it to be mandatory in the HPC Profile. The advanced
> cases we were considering today lie outside the scope of the HPCP, but
> this spec is still quite possibly useful for them.

Yes, I think it should be optional in the schema and made mandatory  in
the HPCP (for the 'final' submission to the container).

> 
>> 3. Donal changed the Argument type from normalizedstring to string. If I
>>  recall correctly there was a very long and heated discussion around
>> this in the past (but, happily perhaps, I can't recall details). Could
>> someone who was involved in the definition of this element followup?
> 
> The difference is that xsd:normalizedString trims spaces and xsd:string
> does not. For arguments, it is sometimes necessary to have leading or
> trailing spaces. Occasionally, you even need args that are nothing but
> whitespace. What this spec is supposed to do is to indicate that
> whatever the implementation does, it must get the argument quoting right
> so that (near[*]) arbitrary arguments can be given.

I still can't remember the discussions on this but I believe this was
the reason we allowed empty argument elements and said they must not be
collapsed. The question I have if you change the argument type to a
string is then why do you need multiple argument elements?

Also I don't have a big problem with restricting definitions (e.g., by
removing the filesystem attribute in this application extension) but I
do have a problem with changing types for identically named elements.

> 
>> 4. Working directory - In contrast to Donal's comment I think if this is
>> not present it should not be created.
> 
> If the user doesn't give a working directory, it's up to the implementor
> to do some default way of handling this. Some systems will want to do
> this by running in the home directory, and others will want to create a
> new per-job directory. The only files that the user should count on
> being there are those that they have staged there themselves. (If the
> user does not specify any stagings, they must obviously not be relying
> on any relatively-named files at all. Their choice.)
> 
> Whatever the implementor does, they should document what they do in that
> case. The HPC Profile may wish to restrict this. (I'd recommend that
> they do just that!)

Donal, are you saying that if the directory is not present it should be
up to the implementation to decide what to do? I read your comment as
saying that the specification should state that the directory should be
created.

> 
>> Btw, I am really curious here, how is a user going to specify that they
>> want a job to run in their home directory, wherever that place may be?
>> Surely the exact location may differ from machine to machine.
> 
> This spec (and more particularly the HPC Profile) isn't about defining
> portable jobs anyway. After all, requiring an executable pathname isn't
> even close to portable, and nor is there any mechanism for dealing with
> differences in path separator between platforms. (At least nobody is
> trying to suggest that MacOS 9 should be used as a HPC platform; the
> directory separator scheme there was *much* different...)

Yes, but it is still a common use case to run a job with 'home' being
the working directory, or in a subdirectory relative of home. I think a
way to specify that without giving the full path name isn't too much to ask.

> 
>> 5. Why was GroupName dropped?
> 
> Not portable to non-POSIX platforms I think.
> 
> Donal.
> [* You'd still be limited by the XML 1.0 spec, and there's the whole
>    separate business of understanding the character encodings actually
>    used. Perhaps the spec should say something there, since it is likely
>    that just copying the bytes from the input document won't work. ]

-- 
Andreas Savva
Fujitsu Laboratories Ltd