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

[Niels de Vos]

On Fri, Apr 28, 2017 at 11:42:24AM +0000, Nir Soffer wrote:
> 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.

Indeed, this is one of the issues that I see as well. It would also
introduce an installation order dependency, or different packages would
need to add/update different users. This seems tricky to get right.

 - qemu package creates the "qemu" user
 - glusterfs package creates the "gluster" group
 - which package should add the "qemu" user to the "gluster" group?
 - what about updating existing installations
 - ...

> 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.

This is an option we could add. It will require an configuration option
through a (to be added) libgfapi.so function, and QEMU will need to be
updated to use it. Those are not real problems, but it will not help
current users. I also thought about using getcwd() as fallback location,
but libvirt seems to run QEMU with / as working directory.

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

Yes, maybe. The request to improve debugging came from oVirt developers
or users, so I am interested to hear those opinions first. Once I have a
better feeling for an acceptible solution, I'll make sure to get the
QEMU folks on board too.

Thanks for your reply!
Niels


> 
> > 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170428/120beda4/attachment.sig>