[libvirt] [PATCH][take2][0/2] storage: allow alphabetical names in owner/group of permissions
Hi, This patch set allows alphabetical names in owner/group of permissions in storage XMLs. Change from the initial patch: - store owner/group as strings - As a result, dumpxml of StoragePool could return XML as it is specified Note that in the case of StorageVolume, dumpxml always returns numeric owner/group, i.e., uid and gid, because current libvirt does not store parameters of a volume into an external file but collect info of the volume from the present filesystem using fstat(). This behavior may lose original parameters even in the case of uid/gid specified. I'm not sure why only StorageVolume does not create a XML file. Anyone knows? I should say here I don't intend to replace using numeric uid/gid with using alphabetical names. This patch intends just to bring ease of use and identifying what is specified for users (may not for end-users though). And I don't still have the answer for the question 'numbers vs. names, which is better?'. Thanks, ozaki-r
On Thu, Apr 16, 2009 at 11:23:51PM +0900, Ryota Ozaki wrote:
Hi,
This patch set allows alphabetical names in owner/group of permissions in storage XMLs.
Change from the initial patch: - store owner/group as strings - As a result, dumpxml of StoragePool could return XML as it is specified
Note that in the case of StorageVolume, dumpxml always returns numeric owner/group, i.e., uid and gid, because current libvirt does not store parameters of a volume into an external file but collect info of the volume from the present filesystem using fstat().
This behavior may lose original parameters even in the case of uid/gid specified. I'm not sure why only StorageVolume does not create a XML file. Anyone knows?
libvirt only stores XML files for top level objects that it manages directly and needs associated state for. In other cases it delegates storaage to the underlying technology. In Xen driver for example, it is delegated to XenD to storage guest configs. In the storage driver we only store the pool configuration and when the pool is active all information about volumes is obtained from the underlying filesystem / storage technology.
I should say here I don't intend to replace using numeric uid/gid with using alphabetical names. This patch intends just to bring ease of use and identifying what is specified for users (may not for end-users though). And I don't still have the answer for the question 'numbers vs. names, which is better?'.
IMHO numbers are better because they are the canonical stored value on the filesystems. No matter which host you access a filesystem from, it will see the same numeric ID. The id <-> name mapping is a per-host property, although a directory / naming service will help make a consistent mapping, this is not guarenteed. As such the numeric ID should be treated as the master value, with name being a derived value. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Apr 16, 2009 at 11:23:51PM +0900, Ryota Ozaki wrote:
I should say here I don't intend to replace using numeric uid/gid with using alphabetical names. This patch intends just to bring ease of use and identifying what is specified for users (may not for end-users though). And I don't still have the answer for the question 'numbers vs. names, which is better?'.
The main problem remains you can't use one or the other without loosing the round trip capability, i.e. what you reserialize after parsing won't carry the same set of informations. And considering we don't know if one is better than the other the status-quo should remain to not break existing uses. If someone start to use names because in his environment it's more resilient than ids, then if the serialization looses or breaks the name, precisely because we did an ID lookup on a different environment, it can be considered a bug. That could be trivially triggered by migrating the domain to a different node where /etc/passwd or /etc/groups is not set up in the same way, though the ID used to label the file owner on the shared storage will be the same. If you stick to ID and not suggest a name lookup might be done you somehow close the gap, because the API defines that you need to keep ID as the identifier available on the cluster. With shared storage like NFS I think ID win over name, because that's how the mapping is maintained, and that's what will be important when you consider the portabilitu of the domain/storage rlated informations. So the main question about this patch (which looks fine from purely a code perspective) is mostly, is this a good idea for the user in the end, and I'm afraid it might be misleading, which kind of offset the convenience value in my opinion. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Ryota Ozaki