[openstack-dev] [nova] A note to contributors - bug triage ftw!

Matt Riedemann mriedem at linux.vnet.ibm.com
Fri Nov 4 23:05:41 UTC 2016


There was a lot of discussion at the Ocata summit about new contributors 
and not so new contributors and what they can do.

Well, bug triage is a pretty simple but very effective way to help out 
and also be productive.

At about 4:30pm CST today (Friday), I was perusing the untriaged nova 
bug list [1] which was at 75. As noted in the nova meeting this week, 
that number is creeping up and we had been good about keeping it <40 for 
most of newton, so we're not doing a good job at triaging new bugs for 
the most part in Ocata.

In about an hour I've triaged 7 bugs and have put up patches for two of 
them.

For a rundown on the process involved there, just in case you're 
wondering about how to do bug triage and the thought process, this is 
how I handled these.

1. https://bugs.launchpad.net/nova/+bug/1639362

There is no log/stacktrace with the error, so its Incomplete. Ask the 
reporter for more details. I also think it's a duplicate of another one 
that I triaged.

2. https://bugs.launchpad.net/os-brick/+bug/1639350

I poked around on this one a bit, it admittedly takes a bit more 
understanding of knowing how the attach volume flow works in the libvirt 
driver, but it's pretty simple to just look at the code. I also pinged 
jgriffith in #openstack-cinder to talk about it a bit. Either way it's 
latent behavior so I marked it as opinion/wishlist for nova.

3. https://bugs.launchpad.net/nova/+bug/1639239

nova-compute fails to start if you're running on s390x - awesome!

Took a second to decide if ISER + s390x is supported in os-brick, but 
then decided that doesn't matter. The real bug here is that os-brick 
raises a ValueError for that combination and the libvirt driver doesn't 
handle it on startup, causing the nova-compute service to crash. This is 
going to be a two-part fix:

a) Land a change in os-brick to raise a more specific exception. Release 
os-brick and bump global-requirements to use that version.

b) Land a change in nova to catch that specific exception, log something 
but don't crash.

4. https://bugs.launchpad.net/nova/+bug/1638813

I didn't even know that get-password CLI existed in novaclient - 
surprise! Even the PTL doesn't know everything about Nova. :)

But from poking around in the code for the CLI and the REST API in Nova, 
it relies on the metadata service, which not every deployment runs. So 
the natural question back to the reporter is, is the metadata service 
running? Mark the bug Incomplete and move on.

5. https://bugs.launchpad.net/nova/+bug/1638381

Unicode failures, yay! This is in mitaka and we don't have a stacktrace, 
so I had to ask the reporter to try and change a LOG.error to 
LOG.exception, recreate and post the results so we can see where it 
really fails. Mark the bug Incomplete and move on.

6. https://bugs.launchpad.net/nova/+bug/1638339

Checked the docs job logs from the linked patch, yup, it fails. Checked 
kombu version in the job log versus what's in stable/mitaka 
upper-constraints, yup, the docs job doesn't use u-c. Marked it 
Confirmed, but not sure we'll actually fix it.

7. https://bugs.launchpad.net/nova/+bug/1636185

Checked the api-ref docs, checked the code, yup, it's wrong. There is 
even a TODO in the server-actions api-ref that we need an API sample for 
that addFloatingIp action. It's a pretty simple fix. Granted, I knew 
where to look, but by doing some simple grepping in the nova repo it 
should be trivial for anyone to find where those docs are generated and 
update it.

----

So what's the point? My point is that within about an hour I'm able to 
triage 7 bugs and put up fixes for 2 of them. That doesn't make me 
awesome. But it means that it's not as hard as maybe people think it is, 
and if everyone did just one new bug per day, we'd have far fewer bugs 
and more of the low-hanging really simple stuff cleaned up.

Getting your code reviewed by the core team...that's another issue as we 
all know and talked about at length at the summit. But these are 
definitely things that everyone can help out with, and reviewing them 
and raising them up in IRC to the core team with a simple, 'hey, this is 
a really simple bug fix, please take a look' can help move things along.

[1] https://goo.gl/RClmZb

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list