abrt integration in vdsm 4.1
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.
On Wed, Apr 19, 2017 at 4:43 PM, Yaniv Bronheim <ybronhei@redhat.com> wrote:
Hi, I posted the new integration [1] to 4.1 - https://gerrit.ovirt.org/#/ q/topic:backport-abrt-intgr for review.
The DocText says: Result: ABRT service is now running on each Hypervisor and exposes crash report as part of vdsm sos output. Why vdsm sos plugins is taking care of abrt report exposure? sos 3.4 has abrt plugin with the possiblity to provide detailed info. Has vdsm sos plugin been tested with sos 3.4 at all?
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- 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>
On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <ybronhei@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.
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.
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 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@redhat.com> wrote:
On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <ybronhei@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.
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.
On Apr 23, 2017 5:21 PM, "Yaniv Bronheim" <ybronhei@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@redhat.com> wrote:
On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <ybronhei@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.
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.
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 <danken@redhat.com> wrote:
On Apr 23, 2017 5:21 PM, "Yaniv Bronheim" <ybronhei@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@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
On Wed, Apr 19, 2017 at 5:43 PM, Yaniv Bronheim <ybronhei@redhat.com> wrote: list"
command, which its output will be reported by our sos plugin.
Thanks, Yaniv Bronhaim.
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.
participants (3)
-
Dan Kenigsberg -
Sandro Bonazzola -
Yaniv Bronheim