Hi Hiro, The issue you raise on slide 6 is key, and one which we were aware of. The question is - is it really an issue? Perhaps the real question is how we relate that object's life-cycle to a "unit of work" - i.e. a job or transaction. But maybe that's a rat hole we don't want to dive down right now. Anyway back to the class/instance question specifically. One way of modeling the HPC service in the EGA reference model would be to separate the concept of the job from the binary - see attached GIF. Each is a separate grid component. Thus multiple jobs depend on a single binary (blast or whatever) that can then be provisioned once. The active state of the deployed binary then equates to the binary being accessible and instantiable (if there is such a word) by the user who wants to run a job. Provisoning of the Job is then facilitated by the provisioning of the binary (already done) and then instantiating it within the context of the cluster. Provisioning of a specific job may of course include the creation of instance specific configuration files (another dependency of a job instance), target data (another dependency...) and command line options. Regards Paul -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Hiro Kishimoto Sent: Monday, October 09, 2006 8:07 AM To: OGSA WG; Bob Thome Subject: Re: [ogsa-wg] Proposed agenda for Oct. 9th call Hi all,
2) HPC profile usecase for EGA reference model (60 min)
Hiro will write-up draft proposal before the call.
I've uploaded my first thoughts of OGSA HPC cluster usecase to GridForge. https://forge.gridforum.org/sf/go/doc13939 Slide deck include: - OGSA HPC cluster - Workload - Batch job: grid component mapping - OGSA HPC usecase diagram - OGSA HPC job status Have a look and give your feedback at the Monday call. Thanks, ---- Hiro Kishimoto -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
