I'll contact QE. Lets continue follow
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 <danken(a)redhat.com> wrote:
On Apr 23, 2017 5:21 PM, "Yaniv Bronheim" <ybronhei(a)redhat.com> 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> wrote:
> On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <ybronhei(a)redhat.com>
> 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.
--