[ovirt-devel] qemu packaging - add the "qemu" user to a "gluster" group?

[Nir Soffer]

On Wed, Apr 26, 2017 at 4:37 PM Niels de Vos <ndevos at redhat.com> wrote:

> Hi,
>
> We're trying to improve the debugability of Gluster backed VMs and one
> of the features for this is to be able to gather "statedumps". These
> statedumps include memory allocation details and other information about
> the Gluster client. QEMU is one of the applications that can be
> configured to use libgfapi.so Gluster client.
>
> Gluster provides the /var/run/gluster/ directory and the libgfapi.so
> library that qemu (in block/gluster.c) uses that. Would there be a
> problem for the "qemu" packages to use add the "qemu" user to a
> "gluster" group?


Yes, if we go in this way, we will have to add qemu to the gluster group for
for debugging gluster: urls, rbd group for rbd: url, etc. This is not
maintainable.

If qemu process writes a statedump running as qemu user, it should keep
it in the only location in the file system where qemu user can write.

But I think the right place for this discussion is qemu-devel, not
ovirt-devel.


> I'm not sure yet how this is done for other packages
> with their own users, but there would be a dependent installation order
> of some kind (needs rpm triggers?).
>
> What is your opinion on this issue, or would you recommend an other
> approach?
>
> Thanks,
> Niels
>
> PS: https://bugzilla.redhat.com/1445569 can be used to reply as well
>
>
> From
> http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.html:
> On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
> > Hi,
> >
> > Recently a new ability to trigger statedumps through the Gluster-CLI [0]
> > has been added. This makes it possible to get statedump from
> > applications that use gfapi. By default, statedumps are saved under
> > /var/run/gluster/... and this directory is only writable by root.
> > Applications that use gfapi do not require root permissions (like QEMU),
> > and therefore fail to write the statedump :-/
> >
> > One approach would be to create a "gluster" group and give the group
> > permissions to write to /var/run/gluster/... Other 'fixes' include
> > setting ACLs on the directory so that specified users can write there.
> > because many daemons have a "home directory" that does not exist, it
> > probably is not a good idea to use $HOME to store statedumps.
> >
> > What suggestions do others have?
> >
> > Thanks,
> > Niels
> >
> >
> > 0.
> https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedump.md
>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170428/7f728f02/attachment.html>