Mathias Dalheimer wrote:
I just read the protocol of last nights OGSA-telecon: [...] I think this is an very important discussion. In Chicago, we decided that the defintion of an information system is out of scope, but what about the underlying resource model? Basically, we need to identify which resource is capable of executing a job described in JSDL (Candidate Set Generator) and which resource to choose from this set (Execution Planning Service). [...]
We really need to decide what our approach on all this is, and we need to decide *soon* before other people make us do work we don't want to. Let us start by examining the single-job case. In this case, the CSG must take an atomic job description and return a set of candidate ways of executing the job, and the EPS must select between these candidates according to some criteria. This means that we need an information model about the resources available, an information model about the atomic job requests, an information model that describes the "fitness" of a particular job candidate, and an information model of the selection criteria. Let's start by trying to leverage what's out there already. :^) Suggest (but don't require) CIM as the resource information model; that will play well politically in any case. Require JSDL+ (where the + stands for whatever bits other groups or particular schedulers require) for the atomic job descriptions. The fitness descriptor info-model we'll have to define (hopefully extensibly), and I'm totally unsure about what to do on selection criteria; some implementations might not want to use user-configurable selectors. Now, let's think about the more complex multi-job case. The problem here is that we don't have a standardized job workflow language. (The closest thing to a standard is BPEL, but that operates at a completely different level.) This makes life hard; without a standardized job workflow language, we can't say how a multi-job would be expressed to the EPS in the first place. On the other hand, for the CSG it is really much simpler; supporting this case really boils down to just being able to handle a vector of JSDL job descriptions instead of just one at a time (experience shows that this sort of bunching is a Good Idea), and that's a trivial extension. I don't know how scheduling and reservation interact with all this. The other big question is what about data and network handling? This matters for the EPS (and I don't know if the CSG will be reusable for this sort of task) but our draft charter just talks about computational job handling...
This seems to be a lot of work. So before making a statement on the OGSA mailing list, I would like to collect some opinions. What do you think about the resource model? Should we deal with it? Is it out of scope? Do we have the knowledge to deal with it? Can we - if it is out of scope - provide input to another team?
My feeling is "resource info model is out of scope" since the CSG can insulate the EPS from a whole host of different resource info models in the first place. We're not designing the implementation of the service. While we could provide input to people working on an RIM, I do not feel that it should be an explicit goal of our WG; there most certainly isn't a single strategy for candidate set generation... (And I'm not sure if I've answered the question.) Donal.