[GSA-RG] SDL contribution

[Donal K. Fellows]

[Oops, found that I hadn't sent this message. Oh well, only a month late...]

Ariel Oleksiak wrote:
> 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.

As Ariel already knows, the message I wrote was not as civil as I
normally try to go for. However, I was pressed for time to finish it
even as much as I did before I had to go to the airport. :-) I once
again wish to thank Attila for writing that submission; that sort of
thing is *always* the best way to get things done, since it means that
everyone has something definite to agree/disagree with.

Going forward from here, the key steps I see are:

   * Separate out non-scheduling attributes; I recommend that you,
     Attila, think carefully about whether to contribute them to the JSDL
     working group directly, but they're strictly out-of-scope for GSA
     and so probably need not a lot of consideration here. :-) Do note
     however that the JSDL-WG definitely won't tackle VO structure; such
     things are probably better transmitted through message contexts
     (such as SOAP headers) and are not portable. They also tread firmly
     into the space of the various security groups, and they're prickly
     people...

   * Separate out system-specific attributes; looking for greater
     commonality in this area is probably a good thing, but I suspect
     some are likely to always remain part of domain-specific profiles.
     Which is *precisely* how JSDL is meant to be used anyway. It's also
     good to remember that having multiple profiles that can all be
     applied is a good mechanism, especially as it keeps (proto-)specs
     small and easy to understand/compose.

   * Add in all the other things that you think are required for
     scheduling and then formally let the JSDL working group know. :-)

[The following paragraph was going to be its own point, but it's too
long and complex. It includes a lot of me thinking as I type.]

When it comes to application types, things are a bit trickier since
Attila's approach is a bit different to that used by the JSDL-ers (we've
got an extension to JSDL for parallel jobs in OGF public comment *right
now* and really really want any feedback from you all on this, even if
it is just "I like it".) I'm not sure what is the best way to factor in
checkpoint-ability or user-interaction into this; they're both important
features, but I suspect they're orthogonal (both from each other and
also from the nature of parallel execution they're doing) so perhaps
there's a need to characterize these things through resources or other
requirements (we're planning to greatly generalize resources in JSDL
2.0, but that's a good long way off). We - the JSDL people that is -
need to understand this all better. (There are also several notions of
interactive execution, just to make things even more complex!)

Donal.