[edit] WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.

Reporting Bugs

From Obsolete Lustre Wiki
Revision as of 10:55, 26 March 2009 by Docadmin (Talk | contribs)
Jump to: navigation, search



Despite the name, the Bugzilla for Lustre is really an issue tracker, not just a bug tracker. It's a one-stop repository for:

    • bugs
    • enhancement requests
    • patch submission
    • patch review, and dependency tracking

Email is a low-power and error-prone tool for these tasks, and a real bug tracking system is better in dozens of ways. For this reason we ask that all of the above issues be handled exclusively through Bugzilla.

All of the important links on this page are accessible from the front page or the toolbar at the bottom of each Bugzilla page, so you don't need to bookmark them. Searching for Bugs

There are two ways to search for bugs in Bugzilla: the quick way and the detailed way.

Use the quick way if you already know the bug number or just want to search for a keyword. Use the detailed way if you want to search on a specific field or with detailed or complex criteria.

If you want to use the detailed query, but don't really know what all of those things mean, you can read this longer guide.

Filing a Bug

Before visiting the bug reporting form, please take a moment to do a quick search to avoid filing duplicate bugs.

Please fill in as many fields as you can. If your version of Lustre isn't listed, please make a note of that in the bug summary so that we can correct that oversight. Please choose the correct component.

Most importantly, please write a good summary and comment. A descriptive summary will dramatically improve your chances of success, and a good comment will prevent it from being immediately closed as INVALID. At the minimum:

    • Describe the problem that you're solving, the feature that you're adding, or the enhancement that you're requesting.
    • If it's a bug, describe precisely the behaviour that you're seeing and the behaviour that you think is correct.
    • Provide as minimal a test case as possible. For example, if 'tar' is crashing, try to narrow it down to a specific syscall, and then do another test with just that one operation. If you tried to narrow it down without success, tell us what you tried.
    • If you have a patch, please read this page for information about how to create your patch, attach it to the bug, and have it reviewed. Please don't just paste it into a comment.

Priority Bugs

If you have a contract with Cluster File Systems for support of your Lustre project, you will see a group membership tick box. Use that to indicate that the bug is important for your project.

Developers Guide to Lustre Bugzilla

Accepting a Bug

When a bug is first filed, it is assigned to someone and its status is NEW. When that person accepts the bug its status changes to ACCEPTED, which signifies that he has acknowledged the bug and is working on it.

Resolving a Bug

When an issue is resolved and awaiting verification from the person who filed it, it is marked RESOLVED. From here, bugs are either re-opened and become REOPENED, are marked VERIFIED by the person who filed the bug, or are closed for good (when the product ships) and become CLOSED. CLOSED is rarely used.

A bug can be resolved for one of a number of reasons:

  • A fix for the issue was checked into the tree and tested (FIXED).
  • The bug report was too vague, described a non-bug, or is otherwise not useful (INVALID).
  • The issue is valid, but no action will be taken anytime soon (REMIND).
  • The issue is valid, but no action will ever be taken (WONTFIX).
  • The issue cannot be reproduced (WORKSFORME).
  • The issue is already filed elsewhere (DUPLICATE).


A bug may have one or more keywords (http://bugzilla.lustre.org/describekeywords.cgi) associated with it, each of which has a special meaning. Consistent application of keywords allow for extremely useful searches.

By default, the reporter and assignee receive email when changes are made to a bug (you can change your email preferences at http://bugzilla.lustre.org/userprefs.cgi?tab=email). If you are interested in a bug, or want someone else to be involved, enter that person's account name in the Cc field. Any old email address will not work--this person must have a Bugzilla account to be on the Cc list.

Each bug has a list of bugs that it blocks and depends on. This list is updated automatically when you mark a bug as DUPLICATE, but you can also add your own dependency data by adding bugs to these fields. This feature is frequently used to create meta-bugs which are just placeholders to gather dependency data. For example, a "Lustre 1.0" bug would depend on all of the bugs that need to be fixed before Lustre 1.0 is released.

Private Groups

If you are the member of a private group, a checkbox will appear in the bug submission form and in the bug status. Check this box to make the bug visible only to members of the group (typically your organization and CFS staff). This is frequently used for bugs which contain sensitive information or have severe security implications.

Reports and Searches

Bugzilla can generate tables and charts (http://bugzilla.lustre.org/report.cgi) for various criteria. If you want to distribute a chart, please don't link to the chart page itself, because it will re-run the query for each hit. Instead, save the image somewhere, then link to the image directly. Our server thanks you.

Saved Searches

If you find yourself running the same searches frequently, you may wish to save them to the toolbar. It will give you one-click access to the search results that you use the most.

For example, clicking on this link will add a query named "All Bugs" that will show you all open Lustre bugs.

This link will add a query named "Important", which will show you all open bugs with a priority of P3 and higher.

You get the idea.

Personal tools