[openstack-dev] [nova] A note to contributors - bug triage ftw!
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  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
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.
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.
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.
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.
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.
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.
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.
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
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.
More information about the OpenStack-dev