[GSA-RG] SDL contribution

[Kertész Attila]

Dear Donal,

First of all, thanks for your comments. Please find my answers below.

Donal K. Fellows írta:
> keratt at inf.u-szeged.hu wrote:
>> I have just joined this mailing list regarding our talk with Ariel at
>>  Manchester. I prepared a JSDL extension in order to make users able
>> to specify scheduling related attributes. Maybe some of the
>> attributes are still specific, though I tried to be general. I am
>> interested in creating a general extension like the SDL you propose.
>> I am willing to contribute to this work, and hope this documents
>> somehow helps the preparation. Please send questions and comments or
>> suggestions, how to combine our work.
>
> I've not looked in detail at what you propose, but I've got a few
> suggestions based on a quick scan.
>
> First point: consider whether all the elements you describe are required
> in all metascheduler/metabroker configurations. In particular, are they
> universal or are they specific to a particular class of middleware? If
> they are not universal (I know for sure that LDAP is not used everywhere
> and nor are proxies in the sense that I think you're using) then what
> you propose should be split across multiple namespaces (and schemas).
The Middleware and Information System elements meant to be generic. LDAP 
is only one choice, it is not restricted to that.
> Second point: should the middleware itself be characterized as a JSDL
> resource?
>
If your job uses some middleware service, it is reasonable to specify it.
> Third point: how does the JobType work with the ParallelApplication
> extension (formally the JSDL SPMD Application Extension, Version 1.0,
> which is currently in public comment). Is there a need for a separate
> "checkpointable" or "interactive" system that can be composed with the
> others?
>
JobType is definitely needed. I don't understand the last question. 
Checkpointable and interactive jobs need to be handled in a special way, 
though only a few schedulers take them into account, if they do so at all.
> Fourth point: the DataAccessProtocol should be selectable at the level
> of individual files.
>
That's right.
> Fifth point: I don't think jsdl:HostName takes element content.
>
Yes, then CandidateHosts could be used to specify Queues, but it would 
not be obvious.
> Sixth point: RSLSubstitution is *strictly* specific to a particular kind
> of middleware.
>
> Seventh point: I must ask why your JobLocalPath element is better than
> jsdl-posix:WorkingDirectory? They're supposed to be the same thing AIUI.
>
Yes, it can be the same.
> Eighth point: EGEERank is strictly specific to EGEE jobs. Same for all
> the other EGEE* elements. Same for all the NorduGrid (NG*) elements.
>
> Ninth point: I think you'll need a lot more work on Policy. It's a huge
> can of worms...
>
> Tenth point: Other is better written as:
> <xsd:any namespace="##other" processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>
>
> Eleventh point: IsExecutable doesn't belong in this spec, *but* it is
> something that ought to be taken forward.
>
> Twelfth point: Please consider subdividing your list of terms; right
> now, it's a huge list and it's difficult to read through them all.
>

Yes, there are specific attributes I wanted to handle is JSDL, too. I 
took into account only 3 schedulers, and tried to cover all their 
attributes. I agree that resrtucturing is needed for further extensions. 
I did not publish my work to take it as it is, but to let you see what 
has already been done.

Regards,

Attila

> I'm sorry for sounding like I'm just sniping; I'm not really. Thank you
> for sticking your head above the (virtual) parapet and publishing your
> ideas. This is how we make things happen. :-)
>
> Donal.