<div dir="ltr">I have created this gist [1] which shows a simple reproducer and also provides coverage data when using prefork and solo pool cls.<div><br></div><div>That shows that when using prefork the coverage data is simply not captured.</div><div><div><br></div><div>[1] <a href="https://gist.github.com/elyezer/2d8225843451364cbb19af08f4f52de3">https://gist.github.com/elyezer/2d8225843451364cbb19af08f4f52de3</a></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 4:03 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Using the solo thread pool is good to get a one-off coverage report. The one you linked to [3] can be used to talk about the state of pulp smash at that point in time. I spot checked the report and the areas that I knew were incorrectly reported as uncovered before are shown as covered in [3] so that is great.<br>
<br>
For a permanent fix to the coverage problem, I recommend not putting the workaround in place on Jenkins. The test environment needs to run exactly the same as the production infrastructure. As one example, there could be meaningful problems that occur in forking celery environments which would not be discovered in the test environment which would not fork.<br>
<br>
In talking with @asksol he indicates that this is not a known issue in celery. Can an issue with a simple reproducer be filed against celery and we can pick up the technical conversation on that bug? Maybe reply on this thread with a link?<br>
<br>
Thank you for all the work that you've done on this issue. This is not an easy problem. I really appreciate your effort here.<br>
<br>
-Brian<div><div class="h5"><br>
<br>
<br>
On 08/29/2016 08:40 PM, Elyezer Rezende wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
All,<br>
<br>
During this month of August I've been working on making the coverage<br>
report we have for Pulp Automation better. I got stuck many times during<br>
the process but I've finally found something that helped improving it.<br>
<br>
The current coverage report is not reliable since any of the Celery<br>
tasks have its coverage data being captured. Because that we had some<br>
guesses on what could be causing that, we suspected that for some reason<br>
the coverage hook was not being installed and so the data not being<br>
captured, also we suspected that coverage was not playing good on how<br>
Celery forks its processes.<br>
<br>
With those two guesses in mind, I've read Celery and Coverage source<br>
code and also got some help from the community. This allowed me to<br>
discover that Celery uses a forked multiprocessing library called<br>
Billiard [1], knowing that then I started checking if coverage.py was<br>
able to capture coverage data multiprocessing processes [2] and created<br>
a sample Django + Celery application to test some assumptions. The first<br>
one I tested was if coverage.py was really able to capture coverage data<br>
from decorated functions (since celery tasks are decorated functions)<br>
ran by the celery workers, the first try failed since I had to make a<br>
call from a celery task and celery tasks was not being captured at all<br>
which made also the simple decorated function data not be captured. So<br>
my first assumption have failed and I got stuck one more time on the<br>
coverage data not being captured issue. Continuing the research I found<br>
the POOL_CLS configuration for the celery workers, that allowed me to<br>
change how celery deals with concurrency and it happened that using<br>
"solo" or "threads" the coverage data was finally captured.<br>
<br>
Next I checked how coverage.py deals with the multiprocessing built-in<br>
library and discovered that it does a patch [3]. That made me realize<br>
that maybe something similar for the Billiard library will be necessary.<br>
Since just changing the POOL_CLS config works and is easier than<br>
creating a patch for the Billiard plugin to capture coverage data I<br>
dropped this and will proceed only if necessary.<br>
<br>
I checked Pulp code and updated the services that spawn celery processes<br>
to use threads as the POOL_CLS (this also required to install the<br>
threadpool Python package), then I tried to run the Pulp Smash<br>
test_sync_publish for RPM over API, and it was passing before the change<br>
and started failing due to celery workers not being able to proper<br>
handle the process' signals since they are only received by the parent<br>
process. I did not investigate more about why it was failing and gave<br>
"solo" a try, it happened that it worked and I was able to proper<br>
capture coverage data for the pulp.server.async.tasks module which was<br>
not being captured before, finally!<br>
<br>
I went ahead and ran all the Pulp Smash tests which produced the<br>
coverage report [4], that has more captured data from the one available<br>
on Jenkins. Now I need your help on identifying if there is any missing<br>
data to be captured still. Please let me know if you think any module<br>
should have more coverage data than presented by the updated report.<br>
<br>
Finally I am about to send a PR to the pulp repository in order to<br>
update the coverage hook with the changes needed in order to set the<br>
POOL_CLS to solo. The pulp worker template [5] and the<br>
pulp_resource_manager.service [6] need to be patched, again, please let<br>
me know if I am missing something and should patch any other file.<br>
<br>
PS.: I would like to thank all the help I received from Pulp developers<br>
with all my newbie questions about Pulp design. A special thanks to Sean<br>
who created the first version of the coverage data and provided some<br>
initial input about what was missing, Brian who spent about an hour with<br>
me explaining how Pulp workers and resource manager work and also to<br>
provide some insights about what could be the cause for the coverage<br>
data not being captured and Jeremy who listened me all the times I was<br>
frustrated by being stuck. I hope this improved coverage report will<br>
bring us value and the information we need in order to ensure Pulp is<br>
well tested by Pulp Smash.<br>
<br>
[1] <a href="https://github.com/celery/billiard" rel="noreferrer" target="_blank">https://github.com/celery/bill<wbr>iard</a><br>
[2] <a href="http://coverage.readthedocs.io/en/coverage-4.2/subprocess.html" rel="noreferrer" target="_blank">http://coverage.readthedocs.io<wbr>/en/coverage-4.2/subprocess.ht<wbr>ml</a><br>
[3]<br>
<a href="https://bitbucket.org/ned/coveragepy/src/257e52793fb0f28853ddca679f67b158107262bf/coverage/multiproc.py" rel="noreferrer" target="_blank">https://bitbucket.org/ned/cove<wbr>ragepy/src/257e52793fb0f28853d<wbr>dca679f67b158107262bf/<wbr>coverage/multiproc.py</a><br>
[4] <a href="https://dl.dropboxusercontent.com/u/109792/pulp-2-11-coverage-report-20160829/index.html" rel="noreferrer" target="_blank">https://dl.dropboxusercontent.<wbr>com/u/109792/pulp-2-11-coverag<wbr>e-report-20160829/index.html</a><br>
[5] <a href="https://github.com/pulp/pulp/blob/master/server/pulp/server/async/manage_workers.py#L23-L25" rel="noreferrer" target="_blank">https://github.com/pulp/pulp/b<wbr>lob/master/server/pulp/server/<wbr>async/manage_workers.py#L23-<wbr>L25</a><br>
[6] <a href="https://github.com/pulp/pulp/blob/master/server/usr/lib/systemd/system/pulp_resource_manager.service#L10-L12" rel="noreferrer" target="_blank">https://github.com/pulp/pulp/b<wbr>lob/master/server/usr/lib/syst<wbr>emd/system/pulp_resource_manag<wbr>er.service#L10-L12</a><br>
<br>
--<br>
Elyézer Rezende<br>
Senior Quality Engineer<br>
irc: elyezer<br>
<br>
<br></div></div>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Elyézer Rezende<div>Senior Quality Engineer<br><div>irc: elyezer</div></div></div></div>
</div>