[GSA-RG] SDL contribution

[Ariel Oleksiak]

Hi Donal, Attila, and All,

Just to clarify: the doc Attila has sent is just an input to our work on 
definition of needed scheduling attributes (or scheduling description 
language if you prefer). His work has been based on analysis of 3 schedulers 
and adjusted to their functionality.

Therefore what we need to address with regard to this proposal is as 
follows:

1.  Since it's too specific (as Donal rightly noticed :)) we should just 
look through it and identify attributes that are general, really needed, and 
have not been already identified by us. The remaining ones should be moved 
to extensions.

2. It's more focused on a description of scheduler capabilities than 
scheduling requirements while we focused more on the latter in the first 
step. BTW, I updated  an initial schema (which inludes the last Oliver's 
changes) in the gridforge. It is also just a starting point - currently we 
think how to make it more modular and flexible. Anyway, these both proposals 
are a bit complementary so we need to consider whether they should be one 
specification or maybe two separate ones.

Cheers,
Ariel

----- Original Message ----- 
From: "Kertész Attila" <keratt at inf.u-szeged.hu>
To: <gsa-rg at ogf.org>
Sent: Wednesday, May 16, 2007 3:21 PM
Subject: Re: [GSA-RG] SDL contribution


> 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.
>
> --
>  gsa-rg mailing list
>  gsa-rg at ogf.org
>  http://www.ogf.org/mailman/listinfo/gsa-rg
>