[libvirt] [RFC][PATCH] storage: allow alphabetical names in owner/group of permissions

[Ryota Ozaki]

Hi Daniel,

On Mon, Mar 16, 2009 at 6:01 PM, Daniel Veillard <veillard at redhat.com> wrote:
> On Sun, Mar 15, 2009 at 02:47:14AM +0900, Ryota Ozaki wrote:
>> Hi,
>>
>> This patch allows to specify owner/group of permissions in storage XML
>> as alphabetical names.
>>
>> One concern of this patch is since alphabetical names are converted
>> to uid/gid at XML parsing (e.g., virsh pool-define some-pool.xml),
>> the generated XML file for libvirt internal does not contain the original
>> alphabetical names and dumpxml does not as well. Is it better the
>> conversion is done when activated not defined?
>
>  Yes, I'm wondering about this. Usually it's better if the XML
> can round-trip without change (i.e. the exported version is the
> same as the imported one), modulo maybe some reordering of elements.
> But loosing information or distortions in the cycle tend to generate
> problems. So I'm wondering what is in your opinion the added value
> of having livirt do that conversion instead of the layer on top of
> libvirt.

The reason why I want this function is just ease of use because we
usually specify owner/group by names not numbers, but I have no
objection to your concern of loosing information. So I will revise
the patch to fix the problem.

And the reason I did odd implementation is that I worried about the
impact by modifying the internal data structure (apologies I didn't
tell this). How about this point?

>  There is the added problem that the given name might not be portable
> from one node to another, that's true too for uid/gid values but for
> example in the case of networked filesystems, the hardcoded numbers are
> actually more portable than the high level name equivalents.

I thought same thing, but I think it's probably not matter. In many
cases, user accounts would be centrally managed, and if not so, hardcoded
numbers also don't make sense because uid/gid values make sense only
if the corresponding accounts exist. So IMO the portability thing
should be considered in operations.

>  So I'm not sure really if the advantage really outweight clearly
> the potential problems. I don't know, it's probably a matter of use
> cases.

Anyway, I'm sure I will remain the capability to specify with numeric
numbers, so there should be no regression ;-)

>  Otherwise the patch looks fine to me, test case may be harder due
> to the non-portability of the names.

Thanks for reviewing! and I agree with you. If writing test cases,
we need a trick, for example, creating a temporal account that has very
higher unused uid/gid only for the tests.


Thanks again,
  ozaki-r

>
> Daniel
>
> --
> Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
> http://veillard.com/ | virtualization library  http://libvirt.org/
>