Features/SaveToBugzilla

Save exception reports straight to bugzilla

Summary

anaconda's had the ability to save exception reports to another machine via scp for a while now. However this only really helps you if you have another machine nearby that you have an account on. This presents a pretty significant barrier to getting exception reports. In addition, people don't usually include all the information we need in a bug report so we have to go back and forth asking for them to attach files.

Instead, it would be much easier if we supported the ability to save tracebacks to bugzilla.

Owner

• Name: ChrisLumens (clumens@redhat.com)

Current status

• Targeted release: Fedora 10
• Last updated: 2008-10-14
• Percentage of completion: 100% - Feature is complete, bugs are getting filed using it.

Detailed Description

In addition to the existing scp exception saving report, this feature adds support to save straight to bugzilla.redhat.com (or elsewhere - see later for more description of this). It adds a third option to the "Save Exception" dialog in anaconda. The user will be required to have a preexisting bugzilla account - there's no provision to add a new user and then file the bug. This is partially due to python-bugzilla not having support for that feature, and partially as a way to keep bug spam down.

The user is prompted for their account name and password, and a summary for the new bug. We then file the bug and add as an attachment the traceback file. One problem here is the possibility for lots of duplicate bugs being filed, since it's now so easy to file one. To prevent this, we have duplicate bug detection. Part of the traceback is hashed. On new bug reports, the hash is stored in the status_whiteboard. Then before filing a new bug, we query bugzilla to see if there are any preexisting reports with that same hash, indicating the same bug. If so, the user is added to the CC list and their exception report is attached to the bug in case there is slightly new information causing the same traceback.

Either way, the user is notified of what happened and directed to the bug URL for their bug. They then have the only option of quitting anaconda.

Not all distributions that use anaconda use Red Hat's bugzilla, and some don't use any bugzilla instance at all. To handle this, we have an abstraction layer that allows distributors to specify their own bug handling system through anaconda's InstallClasses. A distributor could reference the appropriate bug handling class in their custom InstallClass, put that into a product.img, and anaconda would handle it correctly. This has yet to be tested. For distributions that do use bugzilla, they would just need to instantiate the existing bug handling code with the proper URL.

Benefit to Fedora

We lower the barrier to getting bugs filed about anaconda. Because of the strange environment we are running in, it can be difficult to get debugging information (the user's only computer could be in the middle of an install when an error is hit, for instance). This makes it easier for them to report problems to us provided they have a network connection. The duplicate checking should cut down on the number of bugs we receive that all report the same thing.

Scope

The only package that requires any work is anaconda, as this is totally self-contained. With the impending move to the new bugzilla, we may need to revisit python-bugzilla and make some changes there and possibly also to this code in anaconda.

Test Plan

First, we need a bug in anaconda. Shouldn't be terribly hard to find one of those. Having located one, perform the following tests:

• Attempt to save your bug to bugzilla, but with an invalid account. anaconda should tell you it was unable to login and give you another chance.
• Attempt to save your bug to bugzilla with a valid account, but no description. anaconda should tell you and give you another chance.
• Make sure your bug has not been filed before. Save your bug to bugzilla with all the relevant information. It should churn for a minute, then tell you the saving was successful and give you a URL to the new bug. Check that URL. Your bug should be created, your account should be the owner, your anacdump.txt file should be attached with MIME type text/plain, and there should be a very long hash stored in the status_whiteboard.
• Make sure your bug has been filed before (so, perhaps retry the above test immediately after it succeeds). Save your bug to bugzilla with all the relevant information. It should churn for a minute, then tell you the saving was successful and give you a URL to the new bug. Check that URL. The bug should have already existed, your account should be on the CC list, and your anacdump.txt file should be attached with MIME type text/plain.
• It may also be worth trying the above steps with the network cable detached at crucial moments (like before clicking OK) and verifying that anaconda catches the problem instead of displaying another traceback.

User Experience

• [1] shows this feature in action
• Additional drop-down in to submit traceback to redhat.bugzilla.com

Dependencies

Requires adding python-bugzilla to the stage2 image. This is already in Fedora and is pretty small so there shouldn't be any problems here.

Contingency Plan

No contingency plan necessary since most of this has already been committed.

Documentation

The Fedora Installation Guide does not mention dealing with bug reports at all. We should change this. I added a page to the wiki a while back detailing how to report anaconda bugs - http://fedoraproject.org/wiki/Anaconda/BugReporting. This page should be updated to reflect the new capabilities.

Release Notes

It may be worth pointing out that if people want to use this feature, they will need to create a bugzilla account ahead of time, since anaconda doesn't have a way to do that. Besides that, there's probably nothing worth mentioning in the release notes.