Difference between revisions of "Nova/BugTriage"
(→Step 2: Triage Tagged Bugs) |
(→Weekly bug skimming duty) |
||
| Line 8: | Line 8: | ||
=== Weekly bug skimming duty === | === Weekly bug skimming duty === | ||
| + | |||
| + | In short, do as much as possible before the expertise of the subteams is needed. Also, if you spot potential critical bugs, shout out in the #openstack-nova channel (for markus_z or one of the core reviewers [1]). | ||
| + | |||
| + | As a longer clarification, the duty includes: | ||
| + | * Switch the bug to "incomplete" when crucial information is missing and ask the reporter to provide more information. This includes: | ||
| + | ** steps to reproduce | ||
| + | ** the version of Nova and the novaclient (or os-client) | ||
| + | ** logs (on debug level) | ||
| + | ** environment details depending on the bug | ||
| + | *** libvirt/kvm versions, VMWare version, ... | ||
| + | *** storage type (ceph, LVM, GPFS, ...) | ||
| + | *** network type (nova-network or neutron) | ||
| + | |||
| + | I subscribe myself to bugs when I switch them to "incomplete" to see when responses come in. See "You are not directly subscribed to this bug's notifications." on the right hand side of a Launchpad bug report. | ||
| + | |||
| + | * Close as "invalid" if it is a support request or feature request. | ||
| + | * Switch to "confirm" if you could reproduce the described issue. This is not always possible for you because of missing resources like a ceph storage or something like that. | ||
| + | * Add a tag (or more tags) if the report allows you to narrow down the area which potentially contains the issue. This should be the entry point for subteams to dig deeper to find the root cause and potential solutions. | ||
| + | * Bring critical bugs to the attention of the other contributors. The #openstack-nova channel and/or a ML post is useful. | ||
| + | |||
{| class="wikitable" | {| class="wikitable" | ||
Revision as of 16:36, 20 January 2016
Contents
Nova Bug Triage
The triage of Nova bugs follows the OpenStack-wide process documented on BugTriage. Since Nova is such an active project with a high number of incoming bug reports, we have a separate process for categorizing bugs and distributing the load of triage to a larger group of people.
There is also a weekly Nova bug meeting here: Meetings/NovaBugScrub (not active currently)
Nova specific triaging steps
Weekly bug skimming duty
In short, do as much as possible before the expertise of the subteams is needed. Also, if you spot potential critical bugs, shout out in the #openstack-nova channel (for markus_z or one of the core reviewers [1]).
As a longer clarification, the duty includes:
- Switch the bug to "incomplete" when crucial information is missing and ask the reporter to provide more information. This includes:
- steps to reproduce
- the version of Nova and the novaclient (or os-client)
- logs (on debug level)
- environment details depending on the bug
- libvirt/kvm versions, VMWare version, ...
- storage type (ceph, LVM, GPFS, ...)
- network type (nova-network or neutron)
I subscribe myself to bugs when I switch them to "incomplete" to see when responses come in. See "You are not directly subscribed to this bug's notifications." on the right hand side of a Launchpad bug report.
- Close as "invalid" if it is a support request or feature request.
- Switch to "confirm" if you could reproduce the described issue. This is not always possible for you because of missing resources like a ceph storage or something like that.
- Add a tag (or more tags) if the report allows you to narrow down the area which potentially contains the issue. This should be the entry point for subteams to dig deeper to find the root cause and potential solutions.
- Bring critical bugs to the attention of the other contributors. The #openstack-nova channel and/or a ML post is useful.
| From date | To date | Contributors |
|---|---|---|
| 2016-01-07 | 2016-01-14 | cihand |
| 2016-01-14 | 2016-01-21 | auggy rpodolyaka |
| 2016-01-21 | 2016-01-28 | <your-name-here>, <your-name-here>, |
| 2016-01-28 | 2016-02-04 | <your-name-here>, <your-name-here>, |
| 2016-02-04 | 2016-02-11 | <your-name-here>, <your-name-here>, |
| 2016-02-11 | 2016-02-18 | <your-name-here>, <your-name-here>, |
| 2016-02-18 | 2016-02-25 | <your-name-here>, <your-name-here>, |
| 2016-02-25 | 2016-03-03 | <your-name-here>, <your-name-here>, |
| 2016-03-03 | 2016-03-10 | <your-name-here>, <your-name-here>, |
Step 0: Join nova-bugs team
There is an open group you need to join to get permissions to set bug priorities: https://launchpad.net/~nova-bugs
Step 1: Tagging
All new bugs should be tagged to reflect which part of Nova they are related to. The current list of tags can be found on BugTags. Note that it is fine for a bug to receive more than one tag if appropriate.
Launchpad Query: Untriaged Bugs Without Tags
Anyone is welcome to help with tagging bugs. However, the nova bug scrub team has committed to checking this on a regular basis to keep the untagged bug queue under control. See the meeting link for more information
Step 2: Triage Tagged Bugs
Once new bugs have been tagged, they should be triaged as described on BugTriage. To help make sure that the triage queue stays under control, the following table lists the people that have committed to regularly triaging bugs for a given tag. For a description of each tag, see BugTags.
| Bug tag | Owner(s) | Untriaged Query | All Query |
|---|---|---|---|
| api | Untriaged | All | |
| baremetal | devananda | Untriaged | All |
| cells | alaski | Untriaged | All |
| compute | melwitt | Untriaged | All |
| conductor | dansmith | Untriaged | All |
| console | Untriaged | All | |
| db | Untriaged | All | |
| docker | ewindisch | Untriaged | All |
| ec2 | zul | Untriaged | All |
| hyper-v | alexpilotti | Untriaged | All |
| ironic | jlvillal / mrda / devananda (Ironic PTL) | Untriaged | All |
| libvirt | kashyapc | Untriaged | All |
| live-migration | PaulMurray | Untriaged | All |
| lxc | thomasem | Untriaged | All |
| network | Untriaged | All | |
| nova-manage | melwitt | Untriaged | All |
| novaclient1 | melwitt | Untriaged | All |
| oslo | wendar | Untriaged | All |
| pci | Untriaged | All | |
| postgresql | Untriaged | All | |
| rootwrap | ttx | Untriaged | All |
| scheduler | bauzas | Untriaged | All |
| testing | wendar, jogo, and others | Untriaged | All |
| unified-objects | dansmith | Untriaged | All |
| vmware | tjones | Untriaged | All |
| volumes | ndipanov | Untriaged | All |
| xen | anthonyper, openstack-ci@xenproject.org | Untriaged | All |
| xenserver | bobba | Untriaged | All |
1. novaclient bugs exist in their own project on launchpad, python-novaclient. They are not tagged bugs in the nova project. However, we still need one or more people signed up to make sure novaclient bugs get triaged and looked after.
Step 3: Spotting Bug "Themes"
While the above looks at the area of the code, lets also consider tags for key bug "themes":
- quotas
- availability_zones
- live_migrate
Bug Triage Day
bug triage day is a special day per cycle where we try to shift our focus especially to bug triage.
Liberty
The "bug triage day" for liberty took place at August the 5th, one week before the bug review day. The results are below. We did a good job to prioritize "undecided" bugs, which is a good thing for the following bug review day. We could also reduce the "new" bugs, which could have the potential to be serious issues.
