[openstack-dev] [nova] working on bug reports; what blocks you?

Kashyap Chamarthy kchamart at redhat.com
Sun Mar 20 17:53:33 UTC 2016

On Fri, Mar 18, 2016 at 07:01:34PM +0100, Markus Zoeller wrote:
> Kashyap Chamarthy <kchamart at redhat.com> wrote on 03/18/2016 07:28:09 AM:


> > Writing a thoughtful report is hard and time-taking.
> Yeah, and I assume that's the reason many bug reports lack that
> information. I have the hope to dig deeper into the logging
> capabilities of Nova during the P cycle, to figure out how much we
> internally already know but don't offer easily enough. 

As you know, we have some bits in place:

  - Guru Meditation Reports[1].  E.g. `kill -s USR1 `pgrep nova-compute`

  - General logging/tracing of API calls via 

  - For Virt drivers, server-side libvirt/QEMU logging.  We have the
    relevant log filters enabled in DevStack[2], so Gate machines have
    these enabled.  For external bugs being reported in this area,
    people have to enable these explicitly and repeat their tests.

  - General logging/tracing of API calls via 'debug|verbose = True'

[1] http://docs.openstack.org/developer/nova/gmr.html
[2] http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova_plugins/functions-libvirt#n104

> In some bug reports I suggested to use sosreport and attach the file
> then, but I didn't see that happen.

Yeah, that's a good idea, if people could remember to do that, as it
adds far more context from the system than merely OpenStack or its
immediate relevant logs, reducing the reporter <-> triager roundtrip.

> In my head there would be openstack CLI commands like these two:
>     $ openstack report-bug <request-id>
>     $ openstack report-bug --last 10m 
> That should then result in an upstream bug report which answers the
> usual questions we have. Don't ask me details how this would happen.

> In an ideal world with unlimited resources we could do that on our own
> without asking the reporter, but I guess we should do the "please 
> recheck if it's in master" thing more often.

We could certainly try.


More information about the OpenStack-dev mailing list