Hi guys, I'm experimenting with python-coverage and have an updates.img against a RHEL 7 tree which successfully starts, stops and saves the resulting data from coverage.
My issue is that when doing a coverage report I don't see much info for anaconda and pyanaconda.
The only line for anaconda is about /usr/sbin/anaconda.
The rest are blivet, pykickstart, meh, dbus and other python modules but not pyanaconda. Any ideas ?
Notice: There are some known issues with coverage: http://nedbatchelder.com/code/coverage/trouble.html
but the version of anaconda I'm using (anaconda-19.31.51) doesn't seem to suffer from them.
-- Alex
I'm experimenting with python-coverage and have an updates.img against a RHEL 7 tree which successfully starts, stops and saves the resulting data from coverage.
My issue is that when doing a coverage report I don't see much info for anaconda and pyanaconda.
The only line for anaconda is about /usr/sbin/anaconda.
The rest are blivet, pykickstart, meh, dbus and other python modules but not pyanaconda. Any ideas ?
Hm, no clever ideas right now, no. Can you link to what patches you've done to anaconda to try it out? My only experience with python-coverage is the "make coverage" target in pykickstart.
- Chris
На 6.02.2014 18:44, Chris Lumens написа:
I'm experimenting with python-coverage and have an updates.img against a RHEL 7 tree which successfully starts, stops and saves the resulting data from coverage.
My issue is that when doing a coverage report I don't see much info for anaconda and pyanaconda.
The only line for anaconda is about /usr/sbin/anaconda.
The rest are blivet, pykickstart, meh, dbus and other python modules but not pyanaconda. Any ideas ?
Hm, no clever ideas right now, no. Can you link to what patches you've done to anaconda to try it out?
It's a single patch to start/stop/save coverage from inside anaconda. I have hard-coded paths and it may not stop/save cleanly in case of a crash or traceback but works well-enough for testing purposes.
To see a sample coverage report on a RHEL 7 system do:
$ mv anaconda.coverage .coverage $ coverage report
-- Alex
I've finally managed to get `coverage report' to report on pyanaconda by changing the initialization line to:
cov = coverage.coverage(data_file='/mnt/sysimage/root/anaconda.coverage', branch=True, source=['/usr/sbin/anaconda', 'pyanaconda'] )
Which misses other modules like pykickstart, yum and blivet from my previous try.
I'm not sure why without the source parameter coverage doesn't pick up pyanaconda (it's in site-packages after all), I've been asking its maintainer about this.
The question now is which modules do we want to have reported ? Only /sbin/anaconda and pyanaconda or more ? Any thoughts are welcome.
-- Alex
I've finally managed to get `coverage report' to report on pyanaconda by changing the initialization line to:
cov = coverage.coverage(data_file='/mnt/sysimage/root/anaconda.coverage', branch=True, source=['/usr/sbin/anaconda', 'pyanaconda'] )
Which misses other modules like pykickstart, yum and blivet from my previous try.
I'm not sure why without the source parameter coverage doesn't pick up pyanaconda (it's in site-packages after all), I've been asking its maintainer about this.
The question now is which modules do we want to have reported ? Only /sbin/anaconda and pyanaconda or more ? Any thoughts are welcome.
I already have a coverage target in pykickstart that I run from time to time, so I'm not concerned about that. I imagine it'd be pretty easy to do the same with blivet. So I guess I'd just stick with pyanaconda for the moment and if we notice serious gaps, we can add other modules later.
- Chris
На 12.02.2014 17:19, Chris Lumens написа:
I already have a coverage target in pykickstart that I run from time to time, so I'm not concerned about that. I imagine it'd be pretty easy to do the same with blivet. So I guess I'd just stick with pyanaconda for the moment and if we notice serious gaps, we can add other modules later.
Sounds good to me and btw QE has already requested coverage support for the other modules. I've just filed a bug for blivet today. See:
https://bugzilla.redhat.com/show_bug.cgi?id=1064895 - python-blivet https://bugzilla.redhat.com/show_bug.cgi?id=1057626 - pyparted
Are you OK with activating coverage when 'debug=1' is passed on the boot command line or should I add a 'coverage' parameter ?
How about the hard-coded path I'm using ? Any suggestions for that?
Let me know your preferences and I'll follow up with patches for review.
-- Alex
Are you OK with activating coverage when 'debug=1' is passed on the boot command line or should I add a 'coverage' parameter ?
I'm fine with using the debug parameter for this. We've got too many parameters already, so I don't like adding new ones unless we absolutely need to.
How about the hard-coded path I'm using ? Any suggestions for that?
I don't have a better suggestion, though putting stuff in root's home directory seems a little bit weird. I suppose if it only happens when debug=1 is set, you can say the user asked for it.
- Chris
На 13.02.2014 17:57, Chris Lumens написа:
Are you OK with activating coverage when 'debug=1' is passed on the boot command line or should I add a 'coverage' parameter ?
I'm fine with using the debug parameter for this. We've got too many parameters already, so I don't like adding new ones unless we absolutely need to.
How about the hard-coded path I'm using ? Any suggestions for that?
I don't have a better suggestion, though putting stuff in root's home directory seems a little bit weird. I suppose if it only happens when debug=1 is set, you can say the user asked for it.
Here's a patch against master. Two things to note:
* It adds Requires: python-coverage to the spec file which if I understand correctly will pull all the necessary requirements when lorax builds the install images;
* I do a quick check of /proc/cmdline contents for "debug=1" and not use any other method to do so b/c my goal is to start coverage as early as possible and not import other modules before that; In my testing this works fine.
I can give it a try on a Rawhide snapshot once it goes in. Just let me know in which package version.
-- Alex
On 02/14/2014 07:21 AM, Alexander Todorov wrote:
+coverage = None
+proc_cmdline = open("/proc/cmdline", "r").read() +if proc_cmdline.find("debug=1") > -1:
- import coverage
- cov = coverage.coverage(data_file="/mnt/sysimage/root/anaconda.coverage",
branch=True,
source=["/usr/sbin/anaconda", "pyanaconda"]
)
- cov.start()
debug=1 on the kernel command line gets pulled into the anaconda cmdline arguments. Would you be ok with starting this after the parseOptions call, based on opts.debug = True, or does it need to start at the very beginning of the file?
На 21.02.2014 17:16, David Shea написа:
On 02/14/2014 07:21 AM, Alexander Todorov wrote:
+coverage = None
+proc_cmdline = open("/proc/cmdline", "r").read() +if proc_cmdline.find("debug=1") > -1:
- import coverage
- cov = coverage.coverage(data_file="/mnt/sysimage/root/anaconda.coverage",
branch=True,
source=["/usr/sbin/anaconda", "pyanaconda"]
)
- cov.start()
debug=1 on the kernel command line gets pulled into the anaconda cmdline arguments. Would you be ok with starting this after the parseOptions call, based on opts.debug = True, or does it need to start at the very beginning of the file?
When coverage starts earlier it collects as much data as possible. I don't know how much we could be missing if this is started later.
-- Alex
Updated patch per: https://bugzilla.redhat.com/show_bug.cgi?id=1066339#c8
anaconda-devel@lists.stg.fedoraproject.org