Hi all... Thinking about the upcoming F2F meeting, we're going to need some strawmen for people to poke fun at. Here's my first go (everything will need XML serialization, of course): CSG has one official operation: GetCandidates(JobDefinition[] atomicJobs) -> Candidate[] Each Candidate is a structure containing: EndpointReference eprOfBESToSubmitThisJobTo JobDefinition configuredAtomicJob ValuationTerm[] descriptionsOfQoSPriceEtc We permit multiple jobs in the request because this is useful in a setting where a CSG is defined hierarchically in terms of other CSGs (a good way of building a wider Grid in my experience). Any scheduling or reservation terms are done by writing extra things into the JobDefinition elements. JSDL is flexible enough for this. EPS needs at least this operation: PlanExecution(JobDefinition atomicJob, SelectionPolicy selector) -> ExecutionPlan I don't know what the SelectionPolicy will look like, but basing it off of Condor ClassAd selection rules might be a good start. The ExecutionPlan is a structure containing at least: EndpointReference eprOfBESToSubmitThisJobTo JobDefinition actualAtomicJobToSubmit ValuationTerm[] descriptionOfQoSPriceEtc (i.e. the contents of the Candidate) but I know more things will be needed to make this really work. The EPS will ask relevant CSG(s) for the candidates for the job submitted, and will then evaluate the policy to pick the best place to submit the job to. The EPS will not submit the job. The EPS *will* secure any reservations/holds required to carry out the selected candidate. However, an EPS really only becomes interesting when we move away from looking at single jobs; it's within the context of a workflow that having a service instead of doing it all by hand makes real sense. At least in my opinion. And I don't think we want to develop a workflow in this group! OK, that's my thoughts for now. Any opinions? Donal.
Hi Donal, I would like to see draft services description and scenarios at the same time or *before* interface straw man. Based on my past experiences, I think scenarios and service descriptions can guide on, shepherd along, and avoid inefficient discussions of interface definitions. Thoughts? ---- Hiro Kishimoto Donal K. Fellows wrote:
Hi all...
Thinking about the upcoming F2F meeting, we're going to need some strawmen for people to poke fun at. Here's my first go (everything will need XML serialization, of course):
CSG has one official operation:
GetCandidates(JobDefinition[] atomicJobs) -> Candidate[]
Each Candidate is a structure containing: EndpointReference eprOfBESToSubmitThisJobTo JobDefinition configuredAtomicJob ValuationTerm[] descriptionsOfQoSPriceEtc
We permit multiple jobs in the request because this is useful in a setting where a CSG is defined hierarchically in terms of other CSGs (a good way of building a wider Grid in my experience).
Any scheduling or reservation terms are done by writing extra things into the JobDefinition elements. JSDL is flexible enough for this.
EPS needs at least this operation:
PlanExecution(JobDefinition atomicJob, SelectionPolicy selector) -> ExecutionPlan
I don't know what the SelectionPolicy will look like, but basing it off of Condor ClassAd selection rules might be a good start.
The ExecutionPlan is a structure containing at least: EndpointReference eprOfBESToSubmitThisJobTo JobDefinition actualAtomicJobToSubmit ValuationTerm[] descriptionOfQoSPriceEtc (i.e. the contents of the Candidate) but I know more things will be needed to make this really work.
The EPS will ask relevant CSG(s) for the candidates for the job submitted, and will then evaluate the policy to pick the best place to submit the job to. The EPS will not submit the job. The EPS *will* secure any reservations/holds required to carry out the selected candidate.
However, an EPS really only becomes interesting when we move away from looking at single jobs; it's within the context of a workflow that having a service instead of doing it all by hand makes real sense. At least in my opinion. And I don't think we want to develop a workflow in this group!
OK, that's my thoughts for now. Any opinions?
Donal.
participants (2)
-
Donal K. Fellows -
Hiro Kishimoto