HPC Job Delegation Profile Working Session
OGF25,
March 4, 2009, 
Catania, Italy
---
Note taker: Ariel Oleksiak
---

Alexander started the session from explaining the main goal of the group which is to define use-cases and requirements for the delegation of HPC jobs between schedulers in different administrative domains.

Alexander:
- There are OGF standards available that can be used for that purpose. For instance, there are job execution standards so it is relatively easy to submit a job. The main  question is how to use all these existing specs together.
- In particular the unresolved question is how to pass responsibility from one scheduler to another and monitor the full job lifecycle.

The basic protocol discussed at OGF23 in Barcelona was presented. It consists of the main 4 phases:
- Session generation
- Handover of responsibility
- Job execution 
- Usage tracking

Alexander:
 - Although WS-Agreement might seem to be the natural choice for the session generation, creation of dynamic WS-Agreement templates can turn out to be too slow. However, this must bed checked in more detail!
 - Similarly, WS-Agreement could be used for handover of responsibility but it is too generic. Therefore, a profile for the presented scenario is required.
 - Description of usage tracking is available only after job execution. Moreover, usage tracking is done only within BES container although a job lifecycle starts earlier: when submitted by end-user.

Bernhard:
- a term ‘usage tracking’ should be related to a running job rather than state changes and processing job request!
Donal
- the same discussion during the activity instance schema session -> conclusion: state changes and usage tracking must be separated

Chris Smith: 
- why not to submit a job first to BES? Then the BES container may delegate a job
- BES has an extendible state model so it may be used for this purpose if needed
- perhaps a specific interface is needed but probably similar to BES (so maybe it’s better to extend it)
Alex:
- first, analysis of what is needed was planned and then decision whether BES extension or something else

Bernhard:
- there are customers with detailed resource requirements, e.g. bandwidth, type of network, etc. so a generic way of expressing requirements is needed

Donal:
- that’s why JSDL is extendable 

The future of the group discussed. Questions raised whether the group should continue its work and, if so, in which way: by forming a new BoF, attempting to influence work of other groups such as GRAAP, JSDL, BES.

Donal:
- outcomes of the group containing identified gaps and recommendations, e.g. narrowing WS-Agreement, need of Activity Instance schema etc., are very valuable
Chris:
- if the group itself feels the work is needed and there are enough people interested in this effort it should be continued; however more visible group’s publicity is expected
-  the best way is spawning a new group, BoF would be a good idea since it might attract people and we could check how many of them are interested
- moving some work to GRAAP or JSDL might cause hiding the results and discourage people which are, for instance, not interested in details of GRAAP

Ramin:
- problem with people willing to work
- there are few people because few projects are working on such issues

Chris:
- this work is a bit more high level than basic low level OGF specs; if a group deals with design rather than only interfaces its usage is limited
	
Wolfgang:
- but the main goal of the group is to analyze interfaces between particular components in the basic scenario and check if specific OGF specifications are sufficient for this scenario

Bernhard:
- maybe the DGrid scheduling interoperability project is relevant and can help in group’s progress?
Ramin:
- yes, but the same group of people is involved in this initiative; we would need other initiatives from other communities