9:36 a.m.
--ofZMSlrAVk9bLeVm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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?
Thanks,
Niels
PS: https://bugzilla.redhat.com/1445569 can be used to reply as well
=46rom http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.h=
tml:
On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
Hi,
=20
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 :-/
=20
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.
=20
What suggestions do others have?
=20
Thanks,
Niels
=20
=20
0. https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedu=
mp.md
--ofZMSlrAVk9bLeVm
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJZAKJrAAoJECXo5AApwsWzvQgP/RQqbBW/rZ6K6/bJsOr4cY16
j8Ts9hubHpPQeGsM5auL7x58f/Yk1v8DZGLMpgihriKA7wrWygeEjGZiYUqw5sKH
oW6wYbMvEjwSZJF7/MN6jq0U9wPY8waOpxNpvdM3mvNvy8EGzT4Yo/SqXmkwcLQM
Q9v22rOffd9LiuvZmr6N7ftE6xwkbe24P0wD9Rsw9E99R33hr8oCAjdNtVo3jgKa
7ZKMwr5AwQPCVmEkY8sa7AKJi7KLB7oitawGsIvlfwyjQRZO0EMvrDxwxnSLwIlg
6X6SjP7XyBNixM35KKDvBoxgBoE7xmh9kniXkqvEmZRPMG3te7/yPoVh55f4UuDK
gtHXgb+xnQ09Z5eJ5+x23mG26jxXCE/18bOPPUpA4APmyfypPO2JpYO6RABrKmrK
IMurqEnuwpY/rBD4UXUnQiLJtB3tBx8kGtc3Hb8VXLCvJhpnzWQNgRGXsuSLcbTs
W29ZWFr97C5VJcMdMsZJ0haGB7bNyrSOcF6xcUtc8Eg6ELz++c6y2t7IlyKaniVW
PAtuZ3ZlaUt8pw6aLJ4UgaE9kfKUgeEMPFgQIQe8UkTNp3H6N+A9P3QGe9fvl16c
LkjXd5wTZuIDxCEKn/iRSx7oJaVoRsd9BmQB61a7XRPSOJI8yyf4JfMN0kL36UUy
c/y5huVBKyY4sTNzYpu2
=mYzO
-----END PGP SIGNATURE-----
--ofZMSlrAVk9bLeVm--
5:08 a.m.
On Wed, Apr 26, 2017 at 3:36 PM, Niels de Vos <ndevos(a)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.
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 <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
7:42 a.m.
On Wed, Apr 26, 2017 at 4:37 PM Niels de Vos <ndevos(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
10:30 a.m.
--r7tUYVWcdYzDJoZW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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(a)redhat.com> wrote:
=20
> 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?
=20
=20
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
=20
> 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 QEM=
U),
> > 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/statedum=
p.md
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
--r7tUYVWcdYzDJoZW
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJZA1HtAAoJECXo5AApwsWzcBkQAIJ0lkRrNnJB/3FZplogle63
IS6AA1w6BXiqvSHpOQpJZibiwu/HQlgw7wq1jUBEl/gfe383I/I9fZ8U41MmtyIP
9GmpUUCEsMOnn3uBBwfyLKRD4qY97wtjj8Xnruan8kV66iU2TxurFIEEFkTAYtlk
kaZgPh7HgvoJlqEiCP0VUnoMIKZtRLA6RQJMGvxR7LGq1d8XR1kpbBMDRUR9up1O
pHKFBvP5wGY+0WMS8sJ0zfug19YEQbkUqjRq8w/iqoNkRGraNcwVFkMcXsH+Rf5C
rP1v7ahyVonzPTmGKBBr+lHQ6etADlWhSUCeAJmKcuGtRBA6DoSMFEOT+7mWlBcb
SRPQiVx6Sz2i9CZgh0VvKB/uyL7PjRlru4qCo7tGpQSuq7KoC45aNzrcfKIt6Iyv
/6EMyrfz69UEW6KJutOm4rLgwY/mGdb2Tp7mrV1//EA9E81pr4BXODjo3/NOCiqe
aRmDUDXj4PcMpre/QTSt3SHxz5oIinmluytQtjBStHBtcYhO8voRskuRwWjfkhSD
gU8udZkvWLNhEoHOGXqve5WFn9lAlVhyatbjkvd430b7dMF0G49e5vKt3+cPvfrH
V/leqrp86IcCg1DbWiEwrkZ89ILgrVz9fB6rhrtgxkvwGUEGi36b5gdF/SJb9x7v
gQeK+KmxWQChP7Bmxh7r
=55t6
-----END PGP SIGNATURE-----
--r7tUYVWcdYzDJoZW--
2797
days inactive
2799
days old
3 comments
3 participants
participants (3)
-
Niels de Vos -
Nir Soffer -
Sandro Bonazzola