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