Minutes (thanks to Fred Maciel for acting as note-taker all this day)

• Donal introduces the working group and scope.
• Andrew, Donal: CSG is always atomic. 
• Jay: a workflow language may create dependencies between atomic jobs. But that’s unknown to CSG, which can create two candidate sets, and EPS needs to find if there is an intersection. Ravi: the EPS is what knows about the dependencies. Jay: generates a recursion that results in problems. Discussion into two-phase reservation, and its own set of problems. Andrew: we are always going to have these race conditions, because e.g. the machine chosen can die during this process.
• SteveM: CSG making a reservation is perhaps a bad idea, but monitoring the reservations is needed. Andrew: this is part of getting data from the information service. Hiro: Business Grid project makes reservations from CSG. But it does not separate EPS and CSG. Jay: not sure if both can be separated at all.
• Jay: what comes back? Donal: JSDL. Jay: how can JSDL describe the resources? Hiro: just the information in JSDL currently.
• Andrew: scheduling is NP-hard, and there will be different kinds of schedulers suited to different areas. If CSG is simple, it can be plugged into multiple kinds of schedulers.
• Tom: “atomic single job” is a single activity? Soonwook: yes, according to JSDL. Andrew: this is good enough to move forward, but remember that we are defining the interface but not the policy, i.e., we are not defining how resource selection should be done but only the interfaces to it. Would be useful to have wider interfaces. Jay: there are functional issues in the design if decrees too much “out of scope”. Simplifications are snowballing. Even if for instance we don’t have a way to represent to workflows this work should give us requirements. Simple case might not generalize. Ravi: to handle this complexity need framework for exchanges instead of defining details, e.g., how to represent constraints. Hiro: RSS charter does not limit scope.
• Andrew: may need to find out about applications, e.g., which versions of BLAST do I have there? There are things that the application will need that the users don’t know about, which constrains where the application is going to run. CSG may have to talk to ACS (Application Contents Service).
• SteveM: One concretized JSDL total or one per candidate? Soonwook: one total. Other people not sure if this is always possible, e.g. if there are two disjoint sets.
• Jay: want an abstract mechanism to construct relationships between abstract specifications of resource metrics, e.g., BLAST MIPS. We need to understand how to decompose the modeling requirements. SteveM: what we are doing to JSDL is creating the base and later adding. Do we come from the top or expand JSDL bottom-up? Jay: not sure which one should be done. General case is better, but extending JSDL is OK.
• Andrew: does not think that JSDL is the language that is needed to exchange information inside RSS.
• Jay: JSDL does not have an extensibility framework (above XML level). Need to define for RSS if we want to go bottom-up or top-down. RSS cries out for more generality than BES.
• Andrew: performance across architectures is application-specific, as tables of coefficients. What that boils down to is that need EPSs that understand application behavior; trying to codify this is out of scope of GGF. We need to define flows, and people create EPSs suitable for BLAST, etc.
• Ravi: might want to get a list of machines from CSG to which a certain patch can be applied; does not have anything to do with “job execution”. Michael: might want also to obtain a list of the hosts in which I can run a job, i.e., only security constraints. 
• Jay: why do we have two (EPS and CSG) instead of n? Additional discussions on the race condition between EPS and CSG.
• Andrew: as global RS, had a thing called actor that was only one more thing to break, so had to rely on Job Manager. 

Open Issues:

• RSS property set - do we need one at all? I don't see a benefit in requiring a particular Info Model from an interface perspective and we're not specifying anything deeper than that (experience says that would be a mistake).
• How to handle large candidate sets while still retaining the ability to handle rich candidate sets. EPRs are insufficient.
• Whether to (and if so, how to) recommend people write an EPS that deals with workflows with coupling constraints.
• Representation for workflows. 

Other Action Items (no particular order):

• Rejig how we're working on to no longer couple reservations into it
• Get the service description document done ASAP.