Hi Hiro, Hiro Kishimoto wrote:
Hi Sergio,
We think Job Manager provides more features than BES including: - Resource allocation (a.k.a. brokering) - Workload management - Reservation (including advance reservation) - On demand application provisioning - On demand data provisioning (more than file staging/de-staging) - On demand container provisioning
thanks for pointing me at the document. Reading the document, I understand that Job Management is a different capability than Job Execution. Is it correct to say that BES identifies a subset of the capabilities part of the macro category Job Management? Or are they different? In my current classification, this is what I've defined so far for the Execution Management capabilities set: ExecMan ExecMan.JobMan This capability is related to the capacity of managing the execution of a job or set of jobs from start to finish. ExecMan.JobDescription This capability is related to the capacity of letting users be able to describe a job submission request based on a machine-processable language. ExecMan.ExecutionAndPlanning This capability is related to the capacity of building schedules for jobs, i.e., the capability of defining mappings between services and resources, possibly with time constraints. ExecMan.CandidateSetGenerator This capability is related to the capacity of determining the set of resources on which a nit of work can execute. ExecMan.Reservation This capability is related to the capacity of managing reservation of resources for future usage. In an earlier version I had also ExecMan.BasicExecution, but after I thought that it should go under the umbrella of Job Management. Another possible view is to see Job Management as a second-level macro category and then specify a third level of classification, e.g. ExecMan ExecMan.JobMan ExecMan.JobMan.BasicExecution ExecMan.JobMan.DataProvisioning ExecMan.JobMan.ExecutionAndPlanning ... can you comment on the different approaches? Keep in mind that the final goal is to use this decomposition to describe a certain Grid middleware. For instance, the gLite WMS provides ExecMan.CandidateSetGenerator, ExecMan.JobMan, ExecMan.ExecutionAndPlanning, etc. Thanks, Sergio
Our EMS scenario document (working draft) gives you more concrete ideas.
https://forge.gridforum.org/sf/go/doc12749
Hope it helps, ---- Hiro Kishimoto
Sergio Andreozzi wrote:
Dear OGSA-WG,
as part of the OMII-Europe project, I'm performing a decomposition of the functionalities provided by a number of Grid middlewares related to our project following the capabilities identified in the OGSA 1.5 document.
A problem I'm dealing with is about the Job Management service. For instance, in the gLite middleware, there are two main categories of services providing job management capability:
1. the Computing Element, that is an abstraction of a batch system exposing an interface to let other services to submit and manage a job; in the near future this component will adopt the OGSA-BES interface, but at the moment it is present in different flavours (GT 2 GRAM, g-Lite CE and CREAM)
2. the Workload Management System (WMS), that is a meta-scheduler and exposes an interface to let other services to submit and manages a job (or collection of jobs or DAGs); the WMS not only does Job Management, but also Execution and Planning, and Candidate Set Generator.
My doubt is the following: from the viewpoint of Job Management, are a meta-scheduler and a computing service semantically different or identical?
If they are identical, is it expected that in a medium future, the BES interface could be extendend to support the number of job types handled by a meta-scheduler, hence the meta-scheduler will expose the same interface of a computing service?
If they are not identical, what are the differences?
Thanks in advance for your comments,
Sergio Andreozzi
-- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi