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

Miroslav Rezanina mrezanin at redhat.com
Wed May 3 13:20:28 UTC 2017


On Fri, Apr 28, 2017 at 11:55:20AM -0300, Ademar Reis wrote:
> On Fri, Apr 28, 2017 at 06:48:00AM -0400, Karen Noel wrote:
> > 
> > +Cole for Fedora/virt
> > +Jeff for for qemu upstream
> > 
> > 
> > ________________________________
> > From: Sandro Bonazzola
> > Sent: Apr 28, 2017 5:08 AM
> > To: Niels de Vos; Miroslav Rezanina; Karen Noel; Doron Fediuck
> > Cc: devel
> > Subject: Re: qemu packaging - add the "qemu" user to a "gluster" group?
> > 
> > >
> > >
> > > On Wed, Apr 26, 2017 at 3:36 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? 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?
> > >
> > >
> > > Adding Miroslav, Karen and Doron.
> > > I'm not sure about how libgfapi is consumed by
> > > qemu-kvm(-ev/-rhev) but if its support is enable by default
> > > and doesn't require additional qemu-kvm sub packages to be
> > > enabled, I would suggest to just
> > > follow https://fedoraproject.org/wiki/Packaging:UsersAndGroups
> > > and add the qemu user to the gluster group in %pre.
> > >
> > > From oVirt point of view, I think it shouldn't affect us very
> > > much. On CentOS Virt SIG we'll consume whatever will come
> > > from qemu-kvm-rhev.
> 
> Please keep in mind that in a not so distant future, gluster
> support in QEMU will be handled by a sub-package (something like
> qemu-kvm-gluster). See https://bugzilla.redhat.com/show_bug.cgi?id=1425820
> 
> (right now gluster support is enabled by default and included in
> the main qemu package, on all installations).
> 
> Thanks.
>    - Ademar


Hi,

upcomming modularization is one of reason I support adding qemu user to
gluster group - we will be able to update solution to work properly
after modularization.

Mirek

> 
> > >
> > >  
> > >>
> > >>
> > >> 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
> > >>
> > >>
> > >
> > >
> > >
> > > -- 
> > >
> > > SANDRO BONAZZOLA
> > >
> > > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
> > >
> > > Red Hat EMEA
> > >
> > > TRIED. TESTED. TRUSTED.
> 
> -- 
> Ademar Reis
> Red Hat
> 
> ^[:wq!


More information about the Devel mailing list