Mailing List Discussions: Comment #5b
Laura F McGinnis wrote:
5b) Furthermore, when talking about the logging & accounting information associated to grid jobs it is crucial to give some kind of definition of a grid job. Many of the UR properties described in the document are ambiguous because it is not clear what constitutes a grid job. An example is StartTime. Is the brokering or stagein phase of a grid job taken into account?
Evaluation: Defer to mailing list
This point has two distinct aspects. 1) The StartTime and EndTime values refer to the time period to which the Usage Record itself applies. For a job (whether grid, batch or flipping hamburgers for minimum wage) one natural interpretation is that the start and end indicate an accounting period that matches when the job is "consuming resources" in some appropriate sense. But strictly the start and end indicate the accounting period, not the job. 2) The term "grid job" is very perjorative, possibly leading people to conclude (erroneously) that the complexity of NorduGrid is the only way to run jobs on the grid (it isn't). We should make sure that the phrase is *not* used in the specification. Instead, we should try to come up with a phrasing that describes the properties of such a job; I don't know for sure, but it may well be some kind of composite job with staging and execution components, so perhaps that would be the best way to do it, with NorduGrid introducing a profiling on top of that to specialize things for their particular circumstances (the way many of these XML-based specifications are meant to be used anyway...) There should be a way to record the usage from one of NorduGrid's jobs, yes, but I'm not sure about the right way to do it. I don't want the standard to end up full of things that only one system can make use of. Donal.
Isn't all we need just a simple nesting e.g. All Jobs are composites of 1 or more Jobs. A Usage Record may contain a reference to one parent Job (rename GlobalJobId to ParentjobId) This handles URs for each node of jobs on clusters, URs for workflows and also Grid Jobs. Or am I missing something? On 4 May 2006, at 22:09, Donal K. Fellows wrote:
Laura F McGinnis wrote:
5b) Furthermore, when talking about the logging & accounting information associated to grid jobs it is crucial to give some kind of definition of a grid job. Many of the UR properties described in the document are ambiguous because it is not clear what constitutes a grid job. An example is StartTime. Is the brokering or stagein phase of a grid job taken into account?
Evaluation: Defer to mailing list
This point has two distinct aspects. 1) The StartTime and EndTime values refer to the time period to which the Usage Record itself applies. For a job (whether grid, batch or flipping hamburgers for minimum wage) one natural interpretation is that the start and end indicate an accounting period that matches when the job is "consuming resources" in some appropriate sense. But strictly the start and end indicate the accounting period, not the job. 2) The term "grid job" is very perjorative, possibly leading people to conclude (erroneously) that the complexity of NorduGrid is the only way to run jobs on the grid (it isn't). We should make sure that the phrase is *not* used in the specification. Instead, we should try to come up with a phrasing that describes the properties of such a job; I don't know for sure, but it may well be some kind of composite job with staging and execution components, so perhaps that would be the best way to do it, with NorduGrid introducing a profiling on top of that to specialize things for their particular circumstances (the way many of these XML-based specifications are meant to be used anyway...)
There should be a way to record the usage from one of NorduGrid's jobs, yes, but I'm not sure about the right way to do it. I don't want the standard to end up full of things that only one system can make use of.
Donal.
Sven Sven.vandenBerghe@uk.fujitsu.com Fujitsu Laboratories of Europe +44 208 606 4651
Sven van den Berghe wrote:
Isn't all we need just a simple nesting e.g.
All Jobs are composites of 1 or more Jobs. A Usage Record may contain a reference to one parent Job (rename GlobalJobId to ParentjobId)
This handles URs for each node of jobs on clusters, URs for workflows and also Grid Jobs.
See my message from 27 April. :-) In summary, a composite would be useful, but it should probably be labelled as and mean just that. Donal.
I agree with the suggestions in that email, provided that there is more than a single level of composition i.e. composite jobs can be parts of higher-level composite jobs. On 5 May 2006, at 10:21, Donal K. Fellows wrote:
Sven van den Berghe wrote:
Isn't all we need just a simple nesting e.g. All Jobs are composites of 1 or more Jobs. A Usage Record may contain a reference to one parent Job (rename GlobalJobId to ParentjobId) This handles URs for each node of jobs on clusters, URs for workflows and also Grid Jobs.
See my message from 27 April. :-) In summary, a composite would be useful, but it should probably be labelled as and mean just that.
Donal.
Sven Sven.vandenBerghe@uk.fujitsu.com Fujitsu Laboratories of Europe +44 208 606 4651
Sven van den Berghe wrote:
I agree with the suggestions in that email, provided that there is more than a single level of composition i.e. composite jobs can be parts of higher-level composite jobs.
I'm actually thinking of using the generalized Composite software pattern, and that is inherently recursive. Donal.
participants (3)
-
Donal K. Fellows -
Laura F McGinnis -
Sven van den Berghe