Nova Bug Triage
The triage of Nova bugs follows the OpenStack-wide process documented on BugTriage.
There is an open group you need to join to get permissions to set bug priorities: https://launchpad.net/~nova-bugs
All new bugs should be tagged to reflect which part of Nova they are related to. The current list of tags can be found below. Note that it is fine for a bug to receive more than one tag if appropriate. Launchpad Query: Untriaged Bugs Without Tags
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. The official (and inofficial) tags are at: https://bugs.launchpad.net/nova/+manage-official-tags
Tag Owner List
|Bug tag||Description||Owner(s)||Untriaged Query||All Query|
|api||Bugs related to the compute REST API implementation||alex_xu, gmann||Untriaged||All|
|api-ref||Bugs related to the compute or placement REST API Reference||takashin||Untriaged||All|
|availability-zones||Issues when segregating resources with availability zones.||bauzas||Untriaged||All|
|cells||Bugs with Nova cells||dansmith||Untriaged||All|
|ceph||Bugs related to the ceph storage solution||jbernard, lyarwood||Untriaged||All|
|cinder||Bugs related to the nova-cinder interaction. If the bug is determined to be in the upstream cinder source, the cinder project should also be added to the "Affects" list||lyarwood||Untriaged||All|
|compute||Bugs in the nova-compute service that are not specific to a virt driver.||melwitt||Untriaged||All|
|conductor||Bugs in the nova-conductor service||dansmith||Untriaged||All|
|config||All bugs related to the config options||stephenfin||Untriaged||All|
|console||Bugs in the nova-console service (including nova-consoleauth, novncproxy, etc)||melwitt||Untriaged||All|
|cyborg||Bugs related to the nova-cyborg interaction||brinzhang||Untriaged||All|
|doc||Bugs which should affect the manuals project or nova internal docs||mriedem / takashin||Untriaged||All|
|db||Database (datastore) issues, including migrations||jaypipes||Untriaged||All|
|gate-failure||Bug reports which are used to categorize failures in the gate||mriedem||Untriaged||All|
|hyper-v||Problems specific to the hyper-v driver||claudiub||Untriaged||All|
|i18n||Issues with internationalization||?||Untriaged||All|
|ironic||Problems specific to the ironic driver||jroll||Untriaged||All|
|libvirt||Problems specific to the libvirt (kvm or qemu) driver||kashyapc / sean-k-mooney, lyarwood||Untriaged||All|
|live-migration||Problems specific when doing live migration.||sean-k-mooney / lyarwood||Untriaged||All|
|low-hanging-fruit||Should be an easy goal for new contributors||free for all||Untriaged||All|
|lxc||Issues specific to LXC virtualization support||?||Untriaged||All|
|needs-attention||Bugs which came up during the bug skimming duty and further steps are unclear.||?||Untriaged||All|
|needs-functional-test||We need a functional test for this to avoid regression.||?||Untriaged||All|
|network||Issues in nova-network||sean-k-mooney||Untriaged||All|
|neutron||Issues with the nova-neutron-interaction. If the bug is determined to be in the upstream neutron source, the neutron project should also be added to the "Affects" list||sean-k-mooney||Untriaged||All|
|notifications||Bugs in notifications||gibi / takashin||Untriaged||All|
|nova-manage||Bugs in the nova-manage utility (docs)||melwitt / tssurya||Untriaged||All|
|numa||Issues where NUMA is involved||stephenfin / sahid / sean-k-mooney||Untriaged||All|
|novaclient||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.||andreykurilin / takashin||Untriaged||All|
|oslo||Bugs related to Oslo integration (oslo-incubator or Oslo libraries). If the bug is determined to be in the upstream oslo source, the oslo project should also be added to the "Affects" list.||gcb||Untriaged||All|
|pci||Bugs regarding pci-devices (includes "pci-passthrough")||stephenfin / sahid / sean-k-mooney||Untriaged||All|
|placement||Bugs regarding the placement API||cdent||Untriaged||All|
|postgresql||PostgreSQL specific bugs.||?||Untriaged||All|
|powervm||PowerVM specific bugs.||?||Untriaged||All|
|quotas||Bugs related to restricting access to resources with quotas||melwitt||Untriaged||All|
|race-condition||Issues which are hard to reproduce due to race conditions. Probably only useful in combination with other tags.||?||Untriaged||All|
|resource-tracker||Issues with the tracking when and where we claim resources.||jaypipes||Untriaged||All|
|rootwrap||Problems with run-as-root commands or the rootwrap framework.||ttx||Untriaged||All|
|s390x||Bugs which affect IBM's s390x architecture (system z)||andrea_s||Untriaged||All|
|scheduler||Bugs in the nova-scheduler service||bauzas / edleafe / jaypipes||Untriaged||All|
|testing||Bugs related to testing (unit tests, functional tests, tempest integration)||gmann / takashin||Untriaged||All|
|unified-objects||Bugs related to the unified-objects work||dansmith||Untriaged||All|
|upgrade||Issues with upgrade from one release to another. Those are usually critical bugs!||dansmith||Untriaged||All|
|vmware||Issues specific to VMware virtualization support.||cdent||Untriaged||All|
|volumes||Issues related to volume support (Cinder integration)||mdbooth / lyarwood||Untriaged||All|
|xen||Issues with the libvirt+xen driver||anthonyper, email@example.com||Untriaged||All|
|xenserver||Issues specific to XenServer/XenAPI virtualization support||BobBall||Untriaged||All|
How to Subscribe to Tags
Weekly bug skimming duty
Nova gets a lot of new bug reports each day. Each bug report needs to be skimmed if it is a valid report, if crucial information is missing and so on. The weekly bug skimming duty should spread the knowledge and effort of that task to multiple people.
|2016-07-11||2016-07-15||johnthetubaguy, siva_krishnan, pumaranikar|
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)
- Close as "invalid" if it is a support request or feature request.
- Switch to "confirm" if you could reproduce the described issue or can otherwise say that this bug report seems valid. 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.
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).
A bug report template can be found at BugReportTemplate
Below are the most frequently asked questions about the bug triage. Please attend the nova bugs team meeting if you have more questions.
Q: What's the goal of the bug skimming duty?
A: In short, reduce the amount of work other developers have to spent to do a proper root cause analysis (and later fix) of bug reports. For this, close the obviously invalid bug reports, confirm the obviously valid bug reports, ask questions if things are unclear.
Q: Do I need to prove that a bug report is valid/invalid before I can set it to
A: No. Sometimes it's not even possible because you don't have the resources. Looking at the code and tests often enables you to make an educated guess. Citing your sources in a comment helps the discussion.
Q: What's the best status to close a bug report if its issue cannot be reproduced?
Invalid. Note: The status
Incomplete is an open state and means "more information is necessary".
Q: How do I handle open bug reports which are
Incomplete for too long?
A: If it is in this state for more than 30 days and no answers to the open questions are given, close it with
Q: How do I handle dependencies to other bugs or TBD features in other projects? For example, I can fix a bug in Nova but I need that a feature in Cinder gets implemented before.
A: Leave a comment in the Nova bug report which explains this dependency and leave a link to the blueprint or bug report of the other project you depend on.
Q: Do I have to double-check bug reports which are
New and have an assignee?
A: Usually not. This bug report has an inconsistent state though. If a bug report has an assignee, it should be
In Progress and have an importance set.