RE: [jsdl-wg] Re: Matching JSDL Terms to Other Specs
Donal, I think that your statement is both incorrect and unjustified. There is much value in CIM for both provisioning and runtime management. There is complexity there also - since the managed environment is quite complex. If you would care to expand further on what is wrong with CIM, I would be happy to address the issues with you. BTW, as regards the requirements of a Job, these can indeed be modeled/associated as instances of SoftwareResource in CIM V2.9. Just because the info is not in JSIM does not mean that it is not in CIM. Andrea
-----Original Message----- From: owner-jsdl-wg@gridforum.org [mailto:owner-jsdl-wg@gridforum.org] On Behalf Of Donal K. Fellows Sent: Thursday, November 11, 2004 2:36 AM To: Ali Anjomshoaa Cc: JSDL WG Subject: Re: [jsdl-wg] Re: Matching JSDL Terms to Other Specs
Ali Anjomshoaa wrote:
Thanks for looking at the intersection of the two though. A useful exercise I think.
I think the key lesson is that we don't need to worry about what's going on in CIM or JSIM; they address a completely different stage of the job lifecycle (i.e. after submission) to JSDL (which is a description of what the submitter wants the job to do and what it needs in order to do it). This is probably a good thing; I've heard many things about CIM and "the roach motel of data integration" was among the more polite... :^)
Donal.
Andrea Westerinen wrote:
Donal, I think that your statement is both incorrect and unjustified. There is much value in CIM for both provisioning and runtime management. There is complexity there also - since the managed environment is quite complex. If you would care to expand further on what is wrong with CIM, I would be happy to address the issues with you.
BTW, as regards the requirements of a Job, these can indeed be modeled/associated as instances of SoftwareResource in CIM V2.9. Just because the info is not in JSIM does not mean that it is not in CIM.
I'd like to start by apologizing for being more than a bit sour at the time. One of my major problems with CIM as a whole is the difficulty of actually locating the particular relevant classes; it's getting so big that it is appreciably difficult to discover which bits are relevant to the particular problem. :^( However, it is not at all clear to me how a job's requirements, whether on software, hardware or data staging, can be described flexibly within the union of CIM 2.9 and JSIM. An example of the sort of problem comes from the process of describing what processor architecture a particular job would like to run on; typically, most jobs are not interested in specifying a processor stepping level(!) and nor do they really care too much about whether it is the latest-and-greatest. Instead, they just know that they need, say, the basic 32-bit x86 instruction set. The problem for CIM is that its default level of description (in the CIM_Processor.Family enumeration for those people following at home) appears to be much finer than that, and there is no defined partial order relation on the enumeration so that automated systems could know that a "Pentium(R) III" satisfies a requirement for "Pentium(R) brand" (which itself is not actually what people would want to write but is the closest that I can spot as I write this) and yet that "68040" wouldn't (i.e. just using greater-than on the numeric code is clearly wrong.) This point relating to partial orderings on enumeration types will apply to virtually anywhere where you've got enumerations that describe both more and less specific things (which I notice in passing is fairly common, and for quite understandable reasons) and will definitely affect anyone wanting to match against an information service using CIM as its fundamental information model. In terms of software requirements it's even less clear, particularly given that transfer of job descriptions between systems is a critical requirement for the Grid and that serialization of links (such as associations) is always an "interesting" topic with the OO community in my experience. I suppose it doesn't help that there isn't yet a tutorial paper on describing a computational job within CIM; while I'd admit that such a description may well be possible, knowing what components to use to do it is non-trivial (which comes back to the point I made earlier about the size of CIM I suppose. :^) For what it's worth, my general impression of CIM to date has been that it is huge and highly capable of describing things once they have been instantiated. By contrast, JSDL is intended to be much smaller and to describe templates for causing the instantiation of jobs. Once those jobs are instantiated of course, they're no longer really accurately describable in JSDL (though it would be possible to construct a most-specific JSDL template which might give rise to the same job) but they may well be described through CIM (that's up to the implementors and deployers, but none of our business.) Hmm, I've rambled a bit here. Sorry! :^) The important facets of what I've said are probably: * JSDL and CIM address different stages of the overall job lifecycle (and this is probably a good thing). * CIM enumerations could do with the possibility of describing a partial ordering on their values. I know that adding POs to CIM is a fairly big change (if nothing else, a quick search|count indicates 1051 potential enumerations to specify!) But is immensely valuable for when trying to match against the model, and that's a process that's critical to template refinement and instantiation (which are in turn key uses of JSDL). * It's not yet clear how CIM can describe all the aspects of a job, and so there's clearly room for tutorial material here. (A job-oriented tutorial would also mitigate against size-of-CIM concerns, since it'd make it much easier for people to ignore the bits they don't need, a bit like how when you're swimming in the ocean you don't care how deep it is since you're only using the surface. :^) If you prefer, we can take this discussion off the JSDL mailing list. ;^) Donal.
Donal, Andrea, many thanks for your contributions to this discussion.
If you prefer, we can take this discussion off the JSDL mailing list. ;^)
No. I'd like this discussion to continue on the list. It is important for both the cgs/CIM/JSIM community and the JSDL community. Cheers, Ali
Donal.
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
Replies inline... Andrea
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Wednesday, December 01, 2004 2:21 AM To: Andrea Westerinen Cc: 'JSDL WG'; cgs-wg@gridforum.org Subject: Re: [jsdl-wg] Re: Matching JSDL Terms to Other Specs
Andrea Westerinen wrote:
Donal, I think that your statement is both incorrect and unjustified. There is much value in CIM for both provisioning and runtime management. There is complexity there also - since the managed environment is quite complex. If you would care to expand further on what is wrong with CIM, I would be happy to address the issues with you.
BTW, as regards the requirements of a Job, these can indeed be modeled/associated as instances of SoftwareResource in CIM V2.9. Just because the info is not in JSIM does not mean that it is not in CIM.
I'd like to start by apologizing for being more than a bit sour at the time. One of my major problems with CIM as a whole is the difficulty of actually locating the particular relevant classes; it's getting so big that it is appreciably difficult to discover which bits are relevant to the particular problem. :^(
<arw> Totally understand your statement here. That is why DMTF is working on 2 things - profiles (sets of classes with explanations (ie, patterns) to solve specific management problems) and a simplified model in CIM V3 (release planned for 1H2005).
However, it is not at all clear to me how a job's requirements, whether on software, hardware or data staging, can be described flexibly within the union of CIM 2.9 and JSIM. An example of the sort of problem comes from the process of describing what processor architecture a particular job would like to run on; typically, most jobs are not interested in specifying a processor stepping level(!) and nor do they really care too much about whether it is the latest-and-greatest. Instead, they just know that they need, say, the basic 32-bit x86 instruction set. The problem for CIM is that its default level of description (in the CIM_Processor.Family enumeration for those people following at home) appears to be much finer than that, and there is no defined partial order relation on the enumeration so that automated systems could know that a "Pentium(R) III" satisfies a requirement for "Pentium(R) brand" (which itself is not actually what people would want to write but is the closest that I can spot as I write this) and yet that "68040" wouldn't (i.e. just using greater-than on the numeric code is clearly wrong.) This point relating to partial orderings on enumeration types will apply to virtually anywhere where you've got enumerations that describe both more and less specific things (which I notice in passing is fairly common, and for quite understandable reasons) and will definitely affect anyone wanting to match against an information service using CIM as its fundamental information model.
<arw> Actually, I would not associate a specific processor (which is what CIM_Processor describes) with a Job's requirements. That is why I referenced SoftwareResource as a way to describe what is needed - that could then be tied to an actual system and its components (if desired) using the LogicalIdentity association. The SoftwareResource describes what is needed by the software in terms of files, memory, ... and the LogicalIdentity can tie that to actual "stuff" when the software is executing.
In terms of software requirements it's even less clear, particularly given that transfer of job descriptions between systems is a critical requirement for the Grid and that serialization of links (such as associations) is always an "interesting" topic with the OO community in my experience. I suppose it doesn't help that there isn't yet a tutorial paper on describing a computational job within CIM; while I'd admit that such a description may well be possible, knowing what components to use to do it is non-trivial (which comes back to the point I made earlier about the size of CIM I suppose. :^)
<arw> Sounds like a Job Profile is key for the DMTF to create very soon. I will take that message back to the System/Devices WG and help with the task.
For what it's worth, my general impression of CIM to date has been that it is huge and highly capable of describing things once they have been instantiated. By contrast, JSDL is intended to be much smaller and to describe templates for causing the instantiation of jobs. Once those jobs are instantiated of course, they're no longer really accurately describable in JSDL (though it would be possible to construct a most-specific JSDL template which might give rise to the same job) but they may well be described through CIM (that's up to the implementors and deployers, but none of our business.)
<arw> I think that CIM can do (and has done) both - but you are right to want to separate the description of needs from the actual implementation. And, it is right to question what seems too hard to do - since that is valid feedback and will lead to a better model.
Hmm, I've rambled a bit here. Sorry! :^) The important facets of what I've said are probably:
* JSDL and CIM address different stages of the overall job lifecycle (and this is probably a good thing).
<arw> I agree that JSDL and JSIM address different stages, but CIM is meant to address both stages. That said, I acknowledge that CIM has more work to do in the "describing what a job needs" category.
* CIM enumerations could do with the possibility of describing a partial ordering on their values. I know that adding POs to CIM is a fairly big change (if nothing else, a quick search|count indicates 1051 potential enumerations to specify!) But is immensely valuable for when trying to match against the model, and that's a process that's critical to template refinement and instantiation (which are in turn key uses of JSDL).
<arw> Agree - this is something being investigated for CIM V3.
* It's not yet clear how CIM can describe all the aspects of a job, and so there's clearly room for tutorial material here. (A job-oriented tutorial would also mitigate against size-of-CIM concerns, since it'd make it much easier for people to ignore the bits they don't need, a bit like how when you're swimming in the ocean you don't care how deep it is since you're only using the surface. :^)
<arw> Agree!
If you prefer, we can take this discussion off the JSDL mailing list. ;^)
<arw> According to Ali, we have to keep it here :-).
Donal.
Andrea Westerinen wrote:
<arw> Actually, I would not associate a specific processor (which is what CIM_Processor describes) with a Job's requirements. That is why I referenced SoftwareResource as a way to describe what is needed - that could then be tied to an actual system and its components (if desired) using the LogicalIdentity association. The SoftwareResource describes what is needed by the software in terms of files, memory, ... and the LogicalIdentity can tie that to actual "stuff" when the software is executing.
FWIW, I wouldn't either. :^) But I know people who would; apparently the details of the processor it the job is running on is important to them.
<arw> Sounds like a Job Profile is key for the DMTF to create very soon. I will take that message back to the System/Devices WG and help with the task.
Cool.
<arw> I think that CIM can do (and has done) both - but you are right to want to separate the description of needs from the actual implementation. And, it is right to question what seems too hard to do - since that is valid feedback and will lead to a better model.
The main trickiness is that it's usually good policy to underspecify jobs to permit them to be understood (and executed) by more systems. Mind you, in the experience of the centre I work at, users tend to overspecify some aspects (which machine the job runs on doesn't usually matter that much in reality) and underspecify others (they virtually never give sensible estimates of how much computation time a job will need, making scheduling a real PITA). Not that I think the solutions to these problems lie in datamodels at all; they're just a necessary part of developing the real solutions.
<arw> I agree that JSDL and JSIM address different stages, but CIM is meant to address both stages. That said, I acknowledge that CIM has more work to do in the "describing what a job needs" category.
You've a long haul ahead. :^) Inexact description of jobs is key... Donal.
participants (3)
-
Ali Anjomshoaa -
Andrea Westerinen -
Donal K. Fellows