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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/