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