participants:
Aleksandr, Andrew,Mark, Mike,John, Emmanouil, Etienne, Johannes, Luigi, Oxana
 
(a)
Debrief notes from the last meeting


Reminder for use case/requirements presenters at OGF30!

Ideas about sessions
PGI-1 - Process session, documents, update on the process
PGI-2 - Requirement presentation (job description, job management)
PGI-3 - Munich: presentation of early specification, thinks that match the requirements (EMI present some things)  & Discussion & Agreement

TBD (Morris): Create sessions for OGF30!


(b)
Discussions on job descriptions based on use cases

Preparation and prioritization for specification & OGF30 presentations.


EGI (compute, all are agreed yes)
-----
34, "pre-configured sw pieces" and/or "software libraries", e.g. global namespace of this applications might be beneficial as well. , etc.
-- agreement yes
-- addressing the needs of users with different skills (OK)
OK

[GENESIS TOO]



35 --> 
Duplicate

37,  "The execution service should provide local log records that permit efficient log analysis and security audit, e.g.
 changes of activity states, faults, user / job mappings,"
-- agreement yes
-- operational requirement
OK

[GENESIS TOO]


43, "The Execution Service MUST provide a way to create Activities. "
-- agreement yes

[GENESIS TOO]
 
OK, 

44, "Activities submitted by Clients to an Execution Service MUST be specified using a well-defined Job Description 
document "
-- agreement yes

[GENESIS TOO]
OK

45, "On creation of an Activity, the Execution Service MUST return to the Client an Activity ID permitting the Client to
 perform subsequent actions (Query, Cancel, ...) on this precise Activity "
-- agreement yes
-- (Activity ID perhaps a little bit detailed)
-- subsequent action 
-- Mark: Activity ID refers to implementation details
-- Mark: After creating an activity, there must be some means to actually permit subsequent with it
-- Oxana: yes
TBD: (perhaps renaming....)

[GENESIS TOO WITH RENAMING]



(DROPPED FOR ALL USE CASES!)
56, Support vectors for operations within Execution service
-- agreement yes
-- why --> major communities from HTC submit a high number of jobs (in vectors), EGI is an HTC infrastructure, therefore
 important, performance expectations are important
-- Andrew: Vector just one example, but performance is what matters!
-- Oxana: Not necessary, but bulk submission is important
-- Andrew: parameter sweep another idea, but GENESIS not against


(DROPPED FOR EGI USECASE)
57, "The execution service MUST have explicitly described limits for its bulk operations. E.g. The execution service may
 have limits with respect to the size of the vector due to implementation aspects and if requests exceed the 
implementation limits the service communicates this via a fault. "
- Mark: how do we determine the limits
- Morris: something that allows us to obtain the limits for the bulk operations
- Andrew: Coupled requirement with bulk in general


SHOULD, MAY out --> MUST

61, The Execution Service interface specification MUST support any Activity running massively-parallel processes using 
MPI and large-scale HPC Systems
-- Andrew/Mark: a lot of devices that are not HPC
-- EGI a must, because it has HPC
-- Change to Execution Service interface rather than Execution Service
-- difference to specification and deployment
-- Mark: There must be a mechanisms for a client to describe that he wants an MPI job executed and means that execution 
services provide that
-- Oxana: ok

[GENESIS TOO]


63, The client must be able to obtain the status of an activity
-- agreement yes
-- Monitoring by end-users

[GENESIS TOO]

64, The Client must be able to obtain the activity status information with different levels of verbosity (basic, 
detailed, more detailed) 
-- agreement yes
-- why different levels of verbosity - users with different expertise, same kind of activity from different...