[glue-wg] Comparison with CIM

[Paul Millar]

Hi John, Laurence, others

Thanks for all the info: that's helped set GLUE in the wider context.

Perhaps we could add this as a FAQ entry somewhere? A "links with industry" 
entry always looks good, I guess.

On Monday 28 April 2008 21:39:40 Laurence Field wrote:
[many things, but ruthlessly culled]
> Sergio may correct me if I am wrong but he is intending to write some CIM
> information providers for Open Pegasus to publish information related to
> grid services.

This would be through WBEM, right?

From what I've seen, I believe there's a few high-level (Enterprise) projects 
that (are purported to) use WBEM under the hood, whether this is using 
WS-Man(agement) or CIM/HTTP as a transport/session, I'm not sure.

I'm also not sure whether their support is for only a subset of the CIM 
schema, or whether it's "generic", so the same software could monitor (and 
control?) grid applications.

Which reminds me: is there any tie-in with the GridCC project?  From their 
FAQ:
	"Why do I need GRIDCC?
	"[...] if you want to use a multi-user/multi-site interactive monitoring
	and control environment then GRIDCC software may be what you
	are looking for."

Sorry, I'm still figuring out how all these pieces fit together!

> [...] However, for all the details it sometimes misses quite a few
> helpful things. :)

As is the way of things, I guess ;-)


[...]
> If the Glue schema becomes on OGF recommendation and we make a 
> vendor extension to the CIM schema, the DMTF representatives will most
> probably take this to the DMTF to find out what the next steps should be
> and if this is relevant to a wider community.

Ah, excellent.


> The Storage Networking Industry Association (SNIA) is a member of the
> DMTF [...]  If you think it might be helpful to get someone [from SNIA]
> involved, I can fish out the details from my email archive and chase this
> up. 

Well, SNIA is another name I've heard of, but with respect to some different 
projects: XAM and SMI-S (although, I have only a little detailed knowledge of 
both)
	http://www.snia.org/forums/xam/
	http://www.snia.org/smi/home

XAM is quite interesting having some features similar to SRM (but somewhat 
lower-level).  They've initially gone for an API-based standard (leaving the 
wire-protocol vendor-specific), but I believe they may eventually standardise 
on a wire-protocol, too.

That said, I'm not sure how much momentum XAM has currently, or what is the 
support for current hardware.

From a dCache perspective, investigating this further is a back-burner 
project, but the SNIA XAM people might be interested in looking at GLUE 
Storage entities, or maybe not: it could be too low-level.

SMI-S seems to build on CIM/WBEM to provide/enhance the support for managing 
distributed storage.  I guess there's some overlap between this and the GLUE 
storage entities.

So, getting in touch with SNIA might be useful.  I suspect that having people 
with an alternative view-point look at GLUE would benefit GLUE in the 
long-run, but would be inventing more work for ourselves in the 
short-term :-/


>  From looking at the UML, I am a little unsure of how this helps in the
> discussion. Please could you explain in more detail why this is relevant?

Well, there was a few fairly general things, mostly from the "being informed 
from:" category (my apologies if this is already widely known):

First, I was (in a naive way) a little concerned that the DMTF/CIM (with 
SNIA /SMI-S) people might be working in isolation and (to some extent) 
duplicating the work in GLUE.  It's good to hear that people in GLUE/OGF and 
both DMTF SNIA are aware of each other.

Second, CIM seems to have the concept of logically partitioning part of some 
physical medium and making it available (page 14, StorageExtent), which seems 
roughly analogous to our original (VO-view independent) idea of a 
StorageSpace.

For example, it's interesting to see how CIM-Schema would model a D1T1 space. 
I think it would be modeled as a CompositeExtent (a subclass of 
StorageExtent), which has two StorageExtents: one a DiskPartition (or 
possibly a LogicalDisk, should we wanted to model the disk-pools too) and a 
TapePartition.

Third, given our discussion on "describing the hardware"; or rather, 
describing some abstraction of the hardware.  We can look at what abstraction 
might make sense from a CIM point-of-view rather than our own ad-hoc 
abstraction.

It's perhaps interesting that the next layer of abstraction (see page 13) from 
MediaAccessDevice is LogicalDevice, which combines real physical hardware 
with the StorageExtent concept.  So, our abstracted hardware (a Datastore) 
would be represented, under CIM-Schema, as a LogicalDisk (a subclass of 
StorageExtent, itself a subclass of LogicalDevice) that is associated with 
multiple MediaPartitions (either DiskPartitions or TapePartitions) of 
a "sufficiently similar" type.

Finally, there's also discussion on how to represent ACLs and policies.  
Again, we could probably "be informed by" CIM's approach here.  I doubt 
anyone writing an info provider will have sufficient time to implement and 
test that they conform to CIM-Schema approach, let alone the information 
consumer figuring out what to make of all this information.  My view is GLUE 
simply shouldn't publish any ACL information: a simple link from UserDomain 
to the objects that UserDomain might interact with should be sufficient, 
right?  At worse, people try a service and find out they're not authorised 
(which is an inevitable possibility, as GLUE can never publish all ACEs).

Also, just as a general comment, I think GLUE's doing reasonably well at 
keeping things simple, when compared to CIM's schema :-)


> I notice that as MediaAccesssDrives:
>
> 1) They have CDROMDrive and DVDDrive with out sub classing from
> OpticalDrive.

Aye, but there's (apparently) nothing they share beyond both being a 
MediaAccessDevice: their "opticalness" is abstracted out by the interface, I 
guess.

> 2) They are missing both SolidStateDrive and Holographic Drive

Yup, although to be fair, it was only you mentioning the holo-drives that I'd 
heard of them being commercially available (last I heard, they were 
vapourwear).

> 3) They do get extra points for a Worm Drive but lose some for the
> missing Warp Drive

True.

Cheers,

Paul.