Hi, I posted the new integration [1] to 4.1 - https://gerrit.ovirt.org/#/ q/topic:backport-abrt-intgr for review.

Abrt is a service that runs in parallel to vdsm and collect binaries and python crashes under /var/run/tmp - to try that out you can crash a qemu process or vdsm with signal -6 and watch the report using "abrt-cli list" command, which its output will be reported by our sos plugin. Thanks, Yaniv Bronhaim. [1] https://bugzilla.redhat.com/show_bug.cgi?id=917062 -- Yaniv Bronhaim. _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <ybronhei(a)redhat.com&gt; wrote: > Hi, I posted the new integration [1] to 4.1 - > https://gerrit.ovirt.org/#/q/topic:backport-abrt-intgr for review. > Abrt is a service that runs in parallel to vdsm and collect binaries and > python crashes under /var/run/tmp - to try that out you can crash a qemu > process or vdsm with signal -6 and watch the report using "abrt-cli list" > command, which its output will be reported by our sos plugin. > > Thanks, > Yaniv Bronhaim. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=917062 I love to see this integration. It could provide us a lot of information about common failures. The downside is that it can also swamp us with meaningless spam. I see that the bug is destined to 4.1.3. It makes sense to me, since it would let us test it thoroughly on master. Did we do extensive testing already? Can a user disable this (per cluster? on each host?) if he does not like to share the data with Fedora? Regards, Dan.

On Apr 23, 2017 5:21 PM, "Yaniv Bronheim" <ybronhei(a)redhat.com&gt; wrote: All, Great to hear the interest. Sandro - Maybe I can install sos-abrt package - I didn't try. However, ovirt collects only vdsm-sos report and I want to include this information there - so it was easier and simplest way to expose it Yaniv - We don't see why not to include it in 4.1, it runs already two weeks or so in master :) and its something that we want for quite long, and its ready ... why not let others benefit from it without waiting for next major release No patch is harmless. When introducing new code to a stable branch, it is your responsibility to explain what does the feature do, what are it's dangers, how well was it tested. Dan - I will raise the need for more intensive testings. I didn't want to share the information with fedora, because I didn't think about it much.. maybe it can be nice. From my point of you, having abrt output locally and exposed by vdsm is enough for ovirt orchestration with abrt. On Fri, Apr 21, 2017 at 2:38 PM Dan Kenigsberg <danken(a)redhat.com&gt; wrote: > On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <ybronhei(a)redhat.com&gt; > wrote: > > Hi, I posted the new integration [1] to 4.1 - > > https://gerrit.ovirt.org/#/q/topic:backport-abrt-intgr for review. > > Abrt is a service that runs in parallel to vdsm and collect binaries and > > python crashes under /var/run/tmp - to try that out you can crash a qemu > > process or vdsm with signal -6 and watch the report using "abrt-cli > list" > > command, which its output will be reported by our sos plugin. > > > > Thanks, > > Yaniv Bronhaim. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=917062 > > I love to see this integration. It could provide us a lot of > information about common failures. > The downside is that it can also swamp us with meaningless spam. > > I see that the bug is destined to 4.1.3. It makes sense to me, since > it would let us test it thoroughly on master. Did we do extensive > testing already? Can a user disable this (per cluster? on each host?) > if he does not like to share the data with Fedora? > > Regards, > Dan. > -- Yaniv Bronhaim. --