I'd like to confirm people's availability for a call this Wednesday at the usual time. A few weeks ago I think we said the next call would be on activity schema, and specifically that we would discuss use cases. Could people contributing use cases let me know if they can be ready this week? -- Andreas Savva
Dear Andreas, Alexander and I will take care of our use case tomorrow. Best regards, Philipp. Andreas Savva schrieb:
I'd like to confirm people's availability for a call this Wednesday at the usual time.
A few weeks ago I think we said the next call would be on activity schema, and specifically that we would discuss use cases. Could people contributing use cases let me know if they can be ready this week?
-- Andreas Savva
-- jsdl-wg mailing list jsdl-wg@ogf.org http://www.ogf.org/mailman/listinfo/jsdl-wg
Since I can't recall what format the use case needs to be provided in, I'll just put it in an email for tomorrow's discussion. Here is a summary of what I'd like to see from the Activity Instance schema. It's a bit high level, but we can go into more details as time goes on. High level use case: want to be able track a job (and its attributes) throughout it's entire life cycle. It is very useful to be able to see various bits of information about a particular job (an activity instance) at various phases within its lifecycle. Different types of information are particularly relevant at different points in the job lifecycle, and the information can be used for various activities such as job monitoring, system diagnosis, and capacity planning. The types of information that should be tracked are as follows: - the point at which an activity has been submitted (and the parameters that were provided at submission) - any state changes that occur. This would include the time of the change, the old state, and the new state. - information about the activity being forwarded from one scheduler to another (pertains to meta-scheduling and peer scheduling use cases) - some report of resources consumed by the job both during the run time of the job, as well as a final "accounting" record that summarizes the job resource usage User roles: end users monitoring job progress and history, administrators who want to diagnose exceptions within the system, and those who want to use this information for capacity planning. Access mechanism: would like to be able to have access to these records during job runtime by querying the BES (for example) and would like to be able to examine a file that contains activity records -- Chris
Hi, please find a sketch of the scheduling use case here https://forge.gridforum.org/sf/go/doc15178?nav=1. We will try to provide more written info in time before the call. Best regards, Philipp. Christopher Smith wrote:
Since I can't recall what format the use case needs to be provided in, I'll just put it in an email for tomorrow's discussion. Here is a summary of what I'd like to see from the Activity Instance schema. It's a bit high level, but we can go into more details as time goes on.
High level use case: want to be able track a job (and its attributes) throughout it's entire life cycle.
It is very useful to be able to see various bits of information about a particular job (an activity instance) at various phases within its lifecycle. Different types of information are particularly relevant at different points in the job lifecycle, and the information can be used for various activities such as job monitoring, system diagnosis, and capacity planning. The types of information that should be tracked are as follows:
- the point at which an activity has been submitted (and the parameters that were provided at submission) - any state changes that occur. This would include the time of the change, the old state, and the new state. - information about the activity being forwarded from one scheduler to another (pertains to meta-scheduling and peer scheduling use cases) - some report of resources consumed by the job both during the run time of the job, as well as a final "accounting" record that summarizes the job resource usage
User roles: end users monitoring job progress and history, administrators who want to diagnose exceptions within the system, and those who want to use this information for capacity planning.
Access mechanism: would like to be able to have access to these records during job runtime by querying the BES (for example) and would like to be able to examine a file that contains activity records
-- Chris
-- jsdl-wg mailing list jsdl-wg@ogf.org http://www.ogf.org/mailman/listinfo/jsdl-wg
Hi, here comes the written info for the scheduling use case: --8<-- snip --8<-- A client sends a request to a scheduler (could be EMS in OGSA speak) using an activity template which describes the requirements of the submitted work unit. The initially receiving (primary) scheduler takes the template and, if it is willing to handle it, creates an activity instance for it, storing the initial template and, if applicable, additional information. The latter should at least include a "provenance record" which denotes that the current scheduler has taken over responsibility for the execution of the given activity. Other candidate information may include scheduling attributes, dependencies to other activities, and the current state of the activity, possibly reusing the BES state model. On activity delegation, the delegator acts like a client towards the potential delegatee, offering the job to another scheduler. Again, if the delegatee is willing to accept the job, it takes over responsibility and the provenance records and depending information (e.g. the expected BES) are updated. If necessary, the activity template may be modified, as long as the manipulation history is kept. Throughout the whole process, state information is constantly updated in the activity record. After activity completion, the resource consumption is written to the activity record. The corresponding entries and dependent parts of the record could then be sealed (marked final) as to denote the completion of the activity. -->8-- snap -->8-- Spanking welcome... Regards, Alexander 2008/4/9, Philipp Wieder <philipp.wieder@udo.edu>:
Hi,
please find a sketch of the scheduling use case here https://forge.gridforum.org/sf/go/doc15178?nav=1. We will try to provide more written info in time before the call.
-- Dipl.-Inform. Alexander Papaspyrou http://ds.e-technik.uni-dortmund.de/~alexp Robotics Research Institute phone : +49(231)755-5058 Information Technology Section fax : +49(231)755-3251 Dortmund University of Technology, Germany
The addition of provenance is one useful addition provided by this concept... especially if the document is being passed around from broker to broker and BES endpoint. For this provenance to be useful it needs to be trusted... how are you going to record who (really) changed thing... signing or something else? And how will you stop the document and change history growing ecessively...? Steven
Steven, 2008/4/16, Steven Newhouse <Steven.Newhouse@microsoft.com>:
The addition of provenance is one useful addition provided by this concept... especially if the document is being passed around from broker to broker and BES endpoint. For this provenance to be useful it needs to be trusted... how are you going to record who (really) changed thing... signing or something else? And how will you stop the document and change history growing ecessively...?
from my point of view, I don't see the document to be "passed around". Instead, I'd like an endpoint where I can access and modify the document throughout the entire process plus the ability to "finalize" a certain version after the activity's lifecycle has ended. This introduces a slightly different notion of trust (the endpoint has to AAA the manipulator of the document). What's more, a model for the handover from one broker to another is necessary, since both have to agree on the delegation *and then* write provenance information both are happy with. Regarding the size, I agree that an activity record could grow pretty large. But I don't see the problem here -- that's up to the implementors of the activity backend. As I said before, I wouldn't pass around the whole document, but a reference to it solely. Anyway, for the document schema itself, I don't think these aspects are an issue (except for the finalization, maybe). When it comes to consuming/providing services, however, we need to discuss that again. Regards, Alexander -- Dipl.-Inform. Alexander Papaspyrou http://ds.e-technik.uni-dortmund.de/~alexp Robotics Research Institute phone : +49(231)755-5058 Information Technology Section fax : +49(231)755-3251 Dortmund University of Technology, Germany
participants (6)
-
Alexander Papaspyrou -
Andreas Savva -
Christopher Smith -
Philipp -
Philipp Wieder
-
Steven Newhouse