Design of mounting in OpenLMI-Storage

Klaus Kaempf kkaempf at suse.de
Fri Mar 1 08:39:44 UTC 2013


Hi Jan,

* Jan Safranek <jsafrane at redhat.com> [Feb 28. 2013 16:54]:
> On 02/28/2013 03:23 PM, Klaus Kaempf wrote:
> 
> I think mounting is asynchronous operation and can take quite lot of
> time (NFS timeouts). Therefore CreateMount will return CIM_Job. It's not
> in the design I posted, but it IMHO should be there.

yes, agreed. The mount call parameters should be modeled as a separate
class, this will allow for future extension without affecting the
mount method signature.

> > 
> > Ideally, CIM would allow to manipulate associations and mounting would
> > be creation of a CIM_Mount association, unmouting would be deletion of
> > it.
> 
> Ideally it would be really nice, but IMHO mounting is not that simple :(.

Right. And the CIM model doesn't treat associations as first class
citizens since you cannot create associations. :-/

> 
> > 
> >>
> >> Any comments are welcome, especially the parts in /italics/ are quite
> >> disturbing to me. And links to any model which already covers mounting
> >> would be greatly appreciated.
> > 
> > WinRM provides AddMountPoint() and Mount() methods for the
> > Win32_Volume class.
> > See http://msdn.microsoft.com/en-us/library/windows/desktop/aa394515(v=vs.85).aspx
> 
> Thanks for pointer! Looking at Win32_Share.Create(), it looks
> synchronous to me. Has Microsoft concept of CIM_Jobs?

They do, in the Hyper-V WMI classes for example:
http://msdn.microsoft.com/en-us/library/cc723874(v=vs.85).aspx

> 
> AFAIK, in CMPI any CIM method call blocks whole provider, doesn't it?

Yes, that's also my understanding.

> I haven't found any functions to tell CIMOM 'I understand the CMPI
> request, but I tell the result to CIMOM later and maybe from different
> thread.'

CMPI has CMPIBroker::attachThread internally which is modeled via
CIM_Job on the CIM level.


Klaus
-- 
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany


More information about the openlmi-devel mailing list