I'll contact QE. Lets continue follow https://bugzilla.redhat.com/show_bug.cgi?id=917062 for more information and requests. This "devel" mail is only aimed for the rest to be aware of this integration
On Sun, Apr 23, 2017 at 6:53 PM Dan Kenigsberg <[email protected]> wrote: > > > On Apr 23, 2017 5:21 PM, "Yaniv Bronheim" <[email protected]> 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 <[email protected]> wrote: > >> On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <[email protected]> >> 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. > > > -- Yaniv Bronhaim.
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
