Design of mounting in OpenLMI-Storage

Jan Safranek jsafrane at redhat.com
Thu Feb 28 15:47:04 UTC 2013


On 02/28/2013 03:23 PM, Klaus Kaempf wrote:
> * Jan Safranek <jsafrane at redhat.com> [Feb 27. 2013 10:33]:
>> So, looking at the CIM_FileImportService, we might get inspired by it
>> and create following classes:
>>
>>   * LMI_MountService
>>       o CreateMount(FS, type, mountpoint, goal, permanent)
> 
> How about leaving the route of CIM methods behind and try to follow
> the REST model ?
> 
> Then "LMI_MountService::CreateMount" would evolve into them WBEM
> operation CreateInstance of e.g. the LMI_MountedFilesystem class.
> 
> ModifyMount() would be WBEM ModifyInstance and DeleteMount()
> (umount I assume) would be DeleteInstance.

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.

>>   * LMI_Mount: inherited from CIM_Mount
>>       o Association between a CIM_FileSystem (local or remote) and
>>         CIM_Directory where it's mounted.
> 
> 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 :(.

> 
>>
>> 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?

AFAIK, in CMPI any CIM method call blocks whole provider, doesn't it? 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.'

Jan


More information about the openlmi-devel mailing list