[REVIEW v3] Storage mounting API
Jan Synacek
jsynacek at redhat.com
Tue Mar 19 09:38:16 UTC 2013
On 03/19/2013 09:30 AM, Jan Safranek wrote:
> On 03/18/2013 03:31 PM, Jan Synacek wrote:
>> I have summarized the draft and written some basic documentation at
>> http://jsynacek.fedorapeople.org/openlmi/
>
> It looks like mounting is getting more and more complicated :). Now we
> have 14 classes only to call simple mount <what> <where> -o <opts>
>
>> [ Description (
>> "Class for representing mount options. Basic boolean properties represent "
>> "filesystem independent mount options (as listed in mount(8)). Options "
>> "'auto' and 'user' are ommited, as they only make sense in /etc/fstab." ) ]
>> class LMI_MountedFileSystemSetting : CIM_SettingData
>
> If 'auto' and 'user' are relevant only to fstab, shouldn't they be in
> some sort of LMI_PermanentMountFileSystemSetting? In addition, Dump and
> FileSystemCheckOrder properties IMHO belongs to a setting class and not
> to managed element - it's /configuration/, not /state/.
Yes, this makes sense. If I get this correctly, this would mean a class for the
service, one for the setting, one for capabilities and then some more for
associations.
>> class MountedFileSystem : CIM_ManagedElement
>
> What is key of this class?
>
>> [ Description (
>> "If not NULL, specifies a directory path where a part of the original "
>> "file hierarchy is remounted. Also signifies use of a bind mount." ) ]
>> string BindDir;
>
> Huh? What is 'original hierarchy'? Is it source directory of the bind
> mount? Can we merge it with FileSystemType='bind' and
> FileSystemSpec='/bind/source'?
Unfortunate wording, I admit. I'll try to fix that.
I think that FileSystemType=bind makes no sense as bind is not a filesystem
type. It's just a remount of *the same filesystem* to somewhere else. Or am I
missing something?
>
>> uint32 ModifyMount(
>> ...
>> [ IN(false), OUT, Description (
>> "Reference to the modified LMI_Mount instance." ) ]
>> LMI_MountedFileSystem REF NewMount,
>>
>> [ IN, Description (
>> "An existing mount." ) ]
>> LMI_MountedFileSystem REF Mount,
>
> These two should be one Mount parameter, on IN it's the mount to modify,
> on OUT it's the new mount point.
>
>> [ Association ]
>> class MountPoint: CIM_Dependency
>> {
>> [ Override("Antecedent"), Description (
>> "MountedFileSystem reference." ) ]
>> CIM_ManagedElement REF MountedSystem;
>>
>> [ Override("Dependent"), Description (
>> "CIM_Directory reference." ) ]
>> CIM_Directory REF Directory;
>
> Is this class really a dependency? Does Directory depend on
> MountedFileSystem?
In a sense, yes, mounted filesystem 'depends' on a directory where it's mounted.
I just wanted to plug the association classes into the CIM model and
CIM_Dependency seemed just about right. Quoting the specification:
"CIM_Dependency is a generic association used to establish dependency
relationships between ManagedElements."
>
>> };
>>
>> [ Association ]
>> class AttachedFileSystem: CIM_Dependency
>> {
>> [ Override("Antecedent"), Description (
>> "MountedFileSystem reference." ) ]
>> CIM_ManagedElement REF MountedSystem;
>>
>> [ Override("Dependent"), Description (
>> "LMI_FileSystem reference." ) ]
>> CIM_ManageElement REF FileSystem;
>
> Dtto.
>
> In addition, we have model with PermanentMount, but there are no methods
> to create/modify it. I know, we don't have any support for it in Blivet
> yet, but if we have the classes, we should also have the methods to
> manipulate them, even though we won't implement them in the first release.
This would be solved by implementing the idea in the first inlined paragraph.
--
Jan Synacek
Software Engineer, Red Hat
More information about the openlmi-devel
mailing list