Bug 1440383
Summary: | RFE: Improve email notifications for failed and successful vmcores by giving suggested commands and other organizational info | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Dave Wysochanski <dwysocha> |
Component: | retrace-server | Assignee: | Dave Wysochanski <dwysocha> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | Dave Wysochanski <dwysocha> |
Priority: | unspecified | ||
Version: | el6 | CC: | jakub, loberman, michal.toman, mkutlak, mmarusak, msuchy |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | retrace-server-1.18.0-1.fc27 retrace-server-1.18.0-1.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-02-13 17:51:56 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dave Wysochanski
2017-04-08 11:02:26 UTC
We should also be dumping the md5sum for the file now if it exists. For now I think I will avoid putting the 'sys' output in the email notification. Proposed new text for success task: The task #167075214 started on optimus.gsslab.rdu2.redhat.com succeeded URL: https://optimus.gsslab.rdu2.redhat.com/manager/167075214 Task directory: /cores/retrace/tasks/167075214 Started: 2017-04-11 15:35:53 Finished: 2017-04-11 15:36:52 Remote file(s): foo-vmcore.tar.gz Md5sum: 214c4daf0cfb594a1376f5f8a07b9c71 foo-vmcore.tar.gz Kernelver: 2.6.32-696.el6.x86_64[ Log: https://optimus.gsslab.rdu2.redhat.com/manager/167075214/misc/retrace-log Crash: retrace-server-interact 167075214 crash Proposed new text for failed task: The task #167075214 started on optimus.gsslab.rdu2.redhat.com failed NOTE: If kernel version detection failed, and you know the kernel version, you may try re-starting the task with the following command. Please check the retrace-log for more information on why the task failed. The following example assumes the vmcores kernel version is 2.6.32-358.el6 on x86_64 arch: $ retrace-server-worker --restart --kernelver 2.6.32-358.el6.x86_64 --arch x86_64 167075214 URL: https://optimus.gsslab.rdu2.redhat.com/manager/167075214 Task directory: /cores/retrace/tasks/167075214 Started: 2017-04-11 15:35:53 Finished: 2017-04-11 15:36:52 Remote file(s): foo-vmcore.tar.gz Md5sum: 214c4daf0cfb594a1376f5f8a07b9c71 foo-vmcore.tar.gz Kernelver: unknown Log: https://optimus.gsslab.rdu2.redhat.com/manager/167075214/misc/retrace-log If this is a custom kernel and the user needs to place the custome Debuginfo in place should we warn of that too and provide text saying. This is a custom kernel and requires the custom Debuginfo to be placed in path xyz on the Optimus path /cores/xxxxx Please do so and resubmit your task using retrace-server-worker --restart --kernelver 2.6.32-642.15.1.el6.qtine2.x86_64 --arch x86_64 123456789 (In reply to loberman from comment #3) > If this is a custom kernel and the user needs to place the custome Debuginfo > in place should we warn of that too and provide text saying. > > This is a custom kernel and requires the custom Debuginfo to be placed in > path xyz on the Optimus path /cores/xxxxx > > Please do so and resubmit your task using > retrace-server-worker --restart --kernelver > 2.6.32-642.15.1.el6.qtine2.x86_64 --arch x86_64 123456789 Good idea though identifying whether it is a custom kernel is probably non-trivial. I may just add a sentence regarding the location of placing a kernel-debuginfo file, i.e. If this is a test or custom kernel version, or for some reason the kernel-debuginfo repository is unavailable, you can place the kernel-debuginfo RPM at /cores/retrace/repos/download/ and restart the task with: $ retrace-server-worker --restart 123456789 I like where are going with this. One think is not to forget, that retrace server also retraces usercores not only vmcores. So when creating email we should check if the task was vmcore or usercore and then add different fields. For example vmcore can have field : Kernelver: 2.6.32-696.el6.x86_64 but usercore should then have fields: Package: coreutils-8.25-15.fc25.x86_64 Executable: /usr/bin/sleep Os_release: Fedora 24 (Twenty Five) Also about the NOTE - how do you plan to generate this message, since there can be different reasons. (In reply to Matej Marušák from comment #5) > I like where are going with this. One think is not to forget, that retrace > server also retraces usercores not only vmcores. So when creating email we > should check if the task was vmcore or usercore and then add different > fields. > For example vmcore can have field : > Kernelver: 2.6.32-696.el6.x86_64 > but usercore should then have fields: > Package: coreutils-8.25-15.fc25.x86_64 > Executable: /usr/bin/sleep > Os_release: Fedora 24 (Twenty Five) > > Also about the NOTE - how do you plan to generate this message, since there > can be different reasons. Agreed and I'd like to be using userspace cores in production for RHEL but this has never worked (see https://bugzilla.redhat.com/show_bug.cgi?id=1292556) despite the fact I've tried multiple times. Maybe we should talk offline about what needs done for deployment to production of userspace cores. I think the 'success' tasks are simple, and checking for the task type is simple. The failure tasks we have a couple options. First, we could just specify a list of general help for things to try. Second, we could make this bug dependent on another bug that would update the status of failure to be more granular. I have been wanting to do the latter for some time for other reasons (for example, does it make sense to say a task "succeeded" if crash fails to run?) so I may try this. Wrong commit / pull request. retrace-server-1.18.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e5741ca105 retrace-server-1.18.0-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc35ca9028 retrace-server-1.18.0-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc35ca9028 retrace-server-1.18.0-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e5741ca105 retrace-server-1.18.0-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. retrace-server-1.18.0-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. |