[GSA-RG] SDL contribution

[Ph. Wieder]

Dear Attila,

thank you for you comparison. It is true that we did not make progress 
visibly (i.e. the document did not change), but we plan to finalise the 
SDL. After Seattle, there will be information on how to proceed.

Yours, Philipp.

keratt at inf.u-szeged.hu wrote:
> Dear All,
>
> first of all thanks for the comments. I'm getting back to rethinking our
> description on scheduling attributes. In UPC, me Ivan and Cesc are working
> on meta-brokering issues, and we are about to revise the BPDL language we
> created before. Since the last OGF meeting I found no step forward in SDL
> design. If the SDL would be finalized, the BPDL should not contain the
> same attributes, and it would be reasonable to use it, and modify BPDL. I
> made a comparison of both langauages attached, according to the currently
> available information. As the next OGF takes place next week, you will
> probably have some time to discuss further improvements. Unfortunatelly we
> cannot be there, therefore I am writting this note.
>
> Regards,
>
> Attila
>
>   
>> [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.
>> --
>>   gsa-rg mailing list
>>   gsa-rg at ogf.org
>>   http://www.ogf.org/mailman/listinfo/gsa-rg
>>
>>     
>> ------------------------------------------------------------------------
>>
>> --
>>   gsa-rg mailing list
>>   gsa-rg at ogf.org
>>   http://www.ogf.org/mailman/listinfo/gsa-rg



-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich

Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. 
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------