[GSA-RG] SDL contribution

Donal K. Fellows donal.k.fellows at manchester.ac.uk
Wed May 16 06:58:49 CDT 2007


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).

Second point: should the middleware itself be characterized as a JSDL
resource?

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?

Fourth point: the DataAccessProtocol should be selectable at the level
of individual files.

Fifth point: I don't think jsdl:HostName takes element content.

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.

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.

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.


More information about the gsa-rg mailing list