Neutron (client, core, FwaaS, LBaaS, VPNaaS) maintains all of its bugs in the following Launchpad projects:
The Neutron Bugs team in Launchpad is used to allow access to the projects above. Members of the above group have the ability to set bug priorities, target bugs to releases, and other administrative tasks around bugs. The administrators of this group are the members of the neutron-drivers-core gerrit group. Non administrators of this group include anyone who is involved with the Neutron project and has a desire to assist with bug triage.
If you would like to join this Launchpad group, it’s best to reach out to a member of the above mentioned neutron-drivers-core team in #openstack-neutron on Freenode and let them know why you would like to be a member. The team is more than happy to add additional bug triage capability, but it helps to know who is requesting access, and IRC is a quick way to make the connection.
As outlined below the bug deputy is a volunteer who wants to help with defect management. Permissions will have to be granted assuming that people sign up on the deputy role. The permission won’t be given freely, a person must show some degree of prior involvement.
Neutron maintains the notion of a “bug deputy”. The bug deputy plays an important role in the Neutron community. As a large project, Neutron is routinely fielding many bug reports. The bug deputy is responsible for acting as a “first contact” for these bug reports and performing initial screening/triaging. The bug deputy is expected to communicate with the various Neutron teams when a bug has been triaged. In addition, the bug deputy should be reporting “High” and “Critical” priority bugs.
To avoid burnout, and to give a chance to everyone to gain experience in defect management, the Neutron bug deputy is a rotating role. The rotation will be set on a period (typically one or two weeks) determined by the team during the weekly Neutron IRC meeting and/or according to holidays. During the Neutron IRC meeting we will expect a volunteer to step up for the period. Members of the Neutron core team are invited to fill in the role, however non-core Neutron contributors who are interested are also encouraged to take up the role.
This contributor is going to be the bug deputy for the period, and he/she will be asked to report to the team during the subsequent IRC meeting. The PTL will also work with the team to assess that everyone gets his/her fair share at fulfilling this duty. It is reasonable to expect some imbalance from time to time, and the team will work together to resolve it to ensure that everyone is 100% effective and well rounded in their role as _custodian_ of Neutron quality. Should the duty load be too much in busy times of the release, the PTL and the team will work together to assess whether more than one deputy is necessary in a given period.
The presence of a bug deputy does not mean the rest of the team is simply off the hook for the period, in fact the bug deputy will have to actively work with the Lieutenants/Drivers, and these should help in getting the bug report moving down the resolution pipeline.
During the period a member acts as bug deputy, he/she is expected to watch bugs filed against the Neutron projects (as listed above) and do a first screening to determine potential severity, tagging, logstash queries, other affected projects, affected releases, etc.
From time to time bugs will be filed and auto-assigned by members of the core team to get them to a swift resolution. Obviously, the deputy is exempt from screening these.
Finally, the PTL will work with the deputy to produce a brief summary of the issues of the week to be shared with the larger team during the weekly IRC meeting and tracked in the meeting notes.
If you are interested in serving as the Neutron bug deputy, there are several steps you will need to follow in order to be prepared.
Many plugins and drivers have backend code that exists in another repository. These repositories may have their own Launchpad projects for bugs. The teams working on the code in these repos assume full responsibility for bug handling in those projects. For this reason, bugs whose solution would exist solely in the plugin/driver repo should not have Neutron in the affected projects section. However, you should add Neutron (Or any other project) to that list only if you expect that a patch is needed to that repo in order to solve the bug.
It’s also worth adding that some of these projects are part of the so called Neutron stadium. Because of that, their release is managed centrally by the Neutron release team; requests for releases need to be funnelled and screened properly before they can happen. To this aim, the process to request a release is as follows:
When screening bug reports, the first step for the bug deputy is to assess how well written the bug report is, and whether there is enough information for anyone else besides the bug submitter to reproduce the bug and come up with a fix. There is plenty of information on the OpenStack wiki on how to write a good bug report and to learn how to tell a good bug report from a bad one. Should the bug report not adhere to these best practices, the bug deputy’s first step would be to redirect the submitter to this section, invite him/her to supply the missing information, and mark the bug report as ‘Incomplete’. For future submissions, the reporter can then use the template provided below to ensure speedy triaging. Done often enough, this practice should (ideally) ensure that in the long run, only ‘good’ bug reports are going to be filed.
The more information you provide, the higher the chance of speedy triaging and resolution: identifying the problem is half the solution. To this aim, when writing a bug report, please consider supplying the following details and following these suggestions:
The process of bug triaging consists of the following steps:
If the bug report is sound, move next:
You are done! Iterate.
More can be found at this Launchpad page. In a nutshell, in order to make a bug report expire automatically, it needs to be unassigned, untargeted, and marked as Incomplete.
The OpenStack community has had Bug Days but they have not been wildly successful. In order to keep the list of open bugs set to a manageable number (more like <100+, rather than closer to 1000+), at the end of each release (in feature freeze and/or during less busy times), the PTL with the help of team will go through the list of open (namely new, opinion, in progress, confirmed, triaged) bugs, and do a major sweep to have the Launchpad Janitor pick them up. This gives 60 days grace period to reporters/assignees to come back and revive the bug. Assuming that at regime, bugs are properly reported, acknowledged and fix-proposed, losing unaddressed issues is not going to be a major issue, but brief stats will be collected to assess how the team is doing over time.
Launchpad’s Bug Tracker allows you to create ad-hoc groups of bugs with tagging.
In the Neutron team, we have a list of agreed tags that we may apply to bugs reported against various aspects of Neutron itself. The list of approved tags used to be available on the wiki, however the section has been moved here, to improve collaborative editing, and keep the information more current. By using a standard set of tags, each explained on this page, we can avoid confusion. A bug report can have more than one tag at any given time.
New tags, or changes in the meaning of existing tags (or deletion), are to be proposed via patch to this section. After discussion, and approval, a member of the bug team will create/delete the tag in Launchpad. Each tag covers an area with an identified go-to contact or Lieutenant, who can provide further insight. Bug queries are provided below for convenience, more will be added over time if needed.
Tag | Description | Contact |
---|---|---|
access-control | A bug affecting RBAC and policy.json | Kevin Benton |
api | A bug affecting the API layer | Salvatore Orlando |
auto-allocated-topology | A bug affecting get-me-a-network | Henry Gessau |
baremetal | A bug affecting Ironic support | Sukhdev Kapur |
db | A bug affecting the DB layer | Henry Gessau |
deprecation | To track config/feature deprecations | Neutron PTL/drivers |
dns | A bug affecting DNS integration | Miguel Lavalle |
doc | A bug affecting in-tree doc | Edgar Magana |
fullstack | A bug in the fullstack subtree | Assaf Muller |
functional-tests | A bug in the functional tests subtree | Assaf Muller |
fwaas | A bug affecting neutron-fwass | Sean Collins |
gate-failure | A bug affecting gate stability | Armando Migliaccio |
ipv6 | A bug affecting IPv6 support | Henry Gessau |
l2-pop | A bug in L2 Population mech driver | Kevin Benton |
l3-bgp | A bug affecting BGP service plugin | Vikram Choudhary |
l3-dvr-backlog | A bug affecting distributed routing | Ryan Moats |
l3-ha | A bug affecting L3 HA (vrrp) | Assaf Muller |
l3-ipam-dhcp | A bug affecting L3/DHCP/metadata | Miguel Lavalle |
lbaas | A bug affecting neutron-lbaas | Brandon Logan |
linuxbridge | A bug affecting ML2/linuxbridge | Sean Collins |
loadimpact | Performance penalty/improvements | Ryan Moats |
logging | An issue with logging guidelines | Matt Riedemann |
low-hanging-fruit | Starter bugs for new contributors | N/A |
metering | A bug affecting the metering layer | ? |
needs-attention | A bug that needs further screening | PTL/Bug Deputy |
opnfv | Reported by/affecting OPNFV initiative | Drivers team |
ops | Reported by or affecting operators | Drivers Team |
oslo | An interop/cross-project issue | Ihar Hrachyshka |
ovs | A bug affecting ML2/OVS | Kevin Benton |
ovs-lib | A bug affecting OVS Lib | Terry Wilson |
py34 | Issues affecting the Python 3 porting | Cedric Brandily |
qos | A bug affecting ML2/QoS | Miguel Ajo |
released-neutronclient | A bug affecting released clients | Kyle Mestery |
release-subproject | A request to release a subproject | Kyle Mestery |
rfe | Feature enhancements being screened | Drivers Team |
rfe-approved | Approved feature enhancements | Drivers Team |
sg-fw | A bug affecting security groups | Kevin Benton |
sriov-pci-pt | A bug affecting Sriov/PCI PassThrough | Moshe Levi |
troubleshooting | An issue affecting ease of debugging | Assaf Muller |
unittest | A bug affecting the unit test subtree | Cedric Brandily |
usability | UX, interoperability, feature parity | PTL/Drivers Team |
vpnaas | A bug affecting neutron-vpnaas | Paul Michali |
xxx-backport-potential | Cherry-pick request for stable team | Ihar Hrachyshka |