Bug 1396629 - Refactor retrace-server so it is easier to test and modify kernel version detection code
Summary: Refactor retrace-server so it is easier to test and modify kernel version det...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: retrace-server
Version: epel7
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Dave Wysochanski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-18 18:40 UTC by Dave Wysochanski
Modified: 2018-02-05 18:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-05 18:43:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
python test program to rework get_kernel_version (6.01 KB, text/x-python)
2018-02-05 18:45 UTC, Dave Wysochanski
no flags Details

Description Dave Wysochanski 2016-11-18 18:40:38 UTC
Description of problem:
Today the only way to test kernel version detection is by submitting a file to retrace-server.  It would be good to factor this piece of code out so we can more easily test and modify it.


Version-Release number of selected component (if applicable):
retrace-server-1.16-1.el6.noarch

Additional info:

Comment 1 Matej Marušák 2017-01-19 13:39:39 UTC
If I understood you correctly, you are talking about this function https://github.com/abrt/retrace-server/blob/master/src/retrace/retrace.py#L481. Am I right? 
How do yo imagine this detection would work? Could you give us some ideas?

Comment 2 Dave Wysochanski 2017-01-24 21:53:20 UTC
(In reply to Matej Marušák from comment #1)
> If I understood you correctly, you are talking about this function
> https://github.com/abrt/retrace-server/blob/master/src/retrace/retrace.
> py#L481. Am I right? 

Yes that is the main function.

> How do yo imagine this detection would work? Could you give us some ideas?

It could be the case that we could re-do one of the commandline tools to add this functionality, or possibly add a new one that does not necessarily have to be user visible in a non-test environment.  It may be ok if there was some way to just run this over a number of vmcore files without a command tool (for example, if we ran python manually, etc).  Goal is mainly to be able to test it with a number of vmcores.

Offhand I don't recall a need to modify the detection code so I'm marking this as a "low" priority for now.  Once the testing infrastructure is there (bug 129078) it may be nice to try to attempt this but I'm not sure how invasive it will be.

Comment 3 Dave Wysochanski 2018-02-05 18:43:28 UTC
I don't think this is too important anymore.  For now when reworking get_kernel_version I just pulled this code out into a separate python test program and ran it against a ton of vmcores.  I compared the existing 'kernelver' file with the new code and then I could see any differences.

There is another bit of code for the arch if we ever rework that but hopefully a similar thing can be done.

Comment 4 Dave Wysochanski 2018-02-05 18:45:02 UTC
Created attachment 1391686 [details]
python test program to rework get_kernel_version


Note You need to log in before you can comment on or make changes to this bug.