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 <[email protected]> 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/devel
signature.asc
Description: PGP signature
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
