#391: re-enable autoqa-results ML ------------------------+--------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.8.0 Component: production | Keywords: ------------------------+--------------------------------------------------- Read these threads: * https://fedorahosted.org/pipermail/autoqa- devel/2011-September/002894.html * https://fedorahosted.org/pipermail/autoqa- devel/2011-October/002898.html
Find and implement fix so that we can easily inspect the test results again.
#391: re-enable autoqa-results ML -------------------------+----------------------- Reporter: kparal | Owner: kparal Type: task | Status: assigned Priority: major | Milestone: 0.8.0 Component: production | Resolution: Keywords: | Blocking: Blocked By: | -------------------------+----------------------- Changes (by kparal):
* owner: => kparal * status: new => assigned
#391: re-enable autoqa-results ML -------------------------+----------------------- Reporter: kparal | Owner: kparal Type: task | Status: assigned Priority: major | Milestone: 0.8.0 Component: production | Resolution: Keywords: | Blocking: Blocked By: | -------------------------+-----------------------
Comment (by kparal):
Fix pushed as 06f2a3a.
I'll now try to deploy that to the staging server and set it to send results to autoqa-results ML. We will then have a better idea about the volume of emails, whether it is now acceptable.
#391: re-enable autoqa-results ML -------------------------+----------------------- Reporter: kparal | Owner: kparal Type: task | Status: assigned Priority: major | Milestone: 0.8.0 Component: production | Resolution: Keywords: | Blocking: Blocked By: | -------------------------+-----------------------
Comment (by kparal):
Deployed to staging and set to send all results to autoqa-results@. We don't execute as many tests on staging as on production, between the difference should be small. Let's revisit this after Christmas and we'll have a better idea about the new email volume.
#391: re-enable autoqa-results ML ------------------------+----------------------- Reporter: kparal | Owner: kparal Type: task | Status: assigned Priority: major | Milestone: 0.8.0 Component: production | Resolution: Keywords: | Blocked By: Blocking: | ------------------------+-----------------------
Comment (by kparal):
Staging seems to be sending around 150 emails/day. On production it should be slightly more. I have consulted with nirik and this amount of traffic should be probably ok. We will find out.
I have decided to do a hotfix on production just applying 06f2a3a to enable these emails. I will leave staging also enabled. We should then receive both production and staging results into autoqa-results (you can differentiate it by the email sender). That can help us find problems in both stable and development versions of autoqa tests. If the traffic is too high, I'll disable emails from staging.
#391: re-enable autoqa-results ML ------------------------+--------------------- Reporter: kparal | Owner: kparal Type: task | Status: closed Priority: major | Milestone: 0.8.0 Component: production | Resolution: fixed Keywords: | Blocked By: Blocking: | ------------------------+--------------------- Changes (by kparal):
* status: assigned => closed * resolution: => fixed
Comment:
All done, autoqa-results now contains results from both production and staging.
#391: re-enable autoqa-results ML ------------------------+----------------------- Reporter: kparal | Owner: kparal Type: task | Status: reopened Priority: major | Milestone: 0.8.0 Component: production | Resolution: Keywords: | Blocked By: Blocking: | ------------------------+----------------------- Changes (by kparal):
* status: closed => reopened * resolution: fixed =>
Comment:
Reopening, production server sends more emails than I expected. I did not account for fc17 rpmlint and rpmguard results. There's quite a lot of them.
I'll disable emails from production server again and think about a better solution.
#391: re-enable autoqa-results ML ------------------------+----------------------- Reporter: kparal | Owner: kparal Type: task | Status: reopened Priority: major | Milestone: 0.8.0 Component: production | Resolution: Keywords: | Blocked By: Blocking: | ------------------------+-----------------------
Comment (by kparal):
I have pushed 2a4618e 'autoqa.conf: add new option result_email_blacklist'. This will help us blacklist some emails (especially rpmlint/rpmguard from rawhide) and lower the amount of email coming to the mailing list. This is a larger patch, so I won't do any hotfixing and I'll wait until autoqa 0.8 is deployed on production. Only after that I'll set up the blacklist and re-enable emails to autoqa- results from production.
I'll leave this ticket open until then.
#391: re-enable autoqa-results ML [waiting for deployment] ------------------------+----------------------- Reporter: kparal | Owner: kparal Type: task | Status: reopened Priority: major | Milestone: 0.8.0 Component: production | Resolution: Keywords: | Blocked By: Blocking: | ------------------------+-----------------------
#391: re-enable autoqa-results ML [waiting for deployment] ------------------------+--------------------- Reporter: kparal | Owner: kparal Type: task | Status: closed Priority: major | Milestone: 0.8.0 Component: production | Resolution: fixed Keywords: | Blocked By: Blocking: | ------------------------+--------------------- Changes (by kparal):
* status: reopened => closed * resolution: => fixed
Comment:
Done, autoqa-results re-enabled on production. Reasonable blacklist enabled:
result_email_blacklist = ^(rpmlint|rpmguard):.*.fc18.*$ ^(rpmlint|rpmguard): (PASSED|FAILED|INFO);.*$ ^depcheck:.*Nothing to do.*$
For staging I blacklisted everything that contains PASSED, FAILED or INFO.
autoqa-devel@lists.fedorahosted.org