[ogsa-bes-wg] Re: [jsdl-wg] Questions and potential changes to JSDL, as seen from HPC Profile point-of-view

[Christopher Smith]

I think you've definitely touched on the problem with using the CIM model,
but I have to imagine that the people discussing these issues in the DMTF
working groups have faced exactly the same issue as we're seeing, and the
result is that they went for this simple approach. So we can go through the
same exercise they did, perhaps with a chance that we arrive at a different
approach which allows us more flexibility, but I'm guessing we'd arrive at
the same place. How do we keep up (in standardization) with the fast
changing world around us? I for one want to make sure that when someone asks
me for a particular OS or processor type, that I can understand the "token"
that I'm given.

-- Chris 


On 12/6/06 01:28, "Donal K. Fellows" <donal.k.fellows at manchester.ac.uk>
wrote:

> Marvin Theimer wrote:
>> Agreed.  Also, one possibility is to explicitly specify some of the
>> commonly occurring ³semi-bound² scenarios, such as ³any x86²
>> architecture.  I¹m not familiar enough with the CIM world to know if
>> they can provide us with guidance on how to solve the problem in general.
> 
> The problem with CIM (certainly up to the most recent release, 2.12) is
> that they model processor types as a pair: (enum value, string) with the
> string being used only when the enum is "Other". Moreover, the only
> matching model that you can have using such a model is exact matching;
> for example, there is no concept that "80386" (the string rendering of
> value 5 for the CIM_Processor.Family field) is effectively subsumed by
> "80486" (value 6). Given that, I'd say that while CIM is a nice catalog
> of processor types (particularly given that someone else is maintaining
> it ;-)) it's utterly impossible to use for resource selection since the
> one thing you can say for sure is that people won't match the processor
> types precisely. What we'd need is some kind of partial ordering (or set
> of POs, I fear) that allows inexact matching of processor types, but
> that is itself quite a bit of work (and it's ongoing work too). And such
> relations are not at all clean to describe in CIM either; although
> they've got a rich relation model, they're about relating classes and
> not values of enumerations. Fixing the model that way would entail a
> major change to the CIM core itself I think, and not just defining more
> classes on top. Either that or changing the specification of the
> processor part of CIM to model processor families as classes, which
> would be very disruptive to what is a pretty static (and hence widely
> deployed) of CIM.
> 
> And IIRC, CIM's OS types (CIM_OperatingSystem.OSType) suffer from the
> same problem. (If I have a binary that works on Win2k, I'd expect it to
> be fine on WinServer2003 for example, but that's not information
> captured within CIM.)
> 
> CIM does description of what is out there well. But it's a very poor
> base for anything with much richer semantics than equality. I hope this
> message explains why adequately.
> 
> Donal.
>