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.