Open Stack

Kashyap Chamarthy <kchamart at redhat.com> wrote on 03/18/2016 07:28:09 AM:

> From: Kashyap Chamarthy <kchamart at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 03/18/2016 07:30 AM
> Subject: Re: [openstack-dev] [nova] working on bug reports; what blocks 
you?
> 
> On Thu, Mar 17, 2016 at 03:28:48PM -0500, Matt Riedemann wrote:
> > On 3/17/2016 11:41 AM, Markus Zoeller wrote:
> > >What are the various reasons which block you to work on bug reports?
> > >This question goes especially to the new contributors but also to the
> > >rest of us. For me, personally, it's that most bug reports miss the
> > >steps to reproduce which allow me to see the issue on my local system
> > >before I start to dig into the code.
> > >
> > >I'm asking this because I'm not sure what the main reasons are that
> > >our bug list is this huge (~1000 open bug reports). Maybe you have
> > >reasons which can be resolved or mitigated by me in my bug czar role.
> > >Let me know.
> 
> Effective bug reporting is top issue for me.  By "effective" I mean:
> 
>   - Not assuming any prior context while writing a report.  (Especially
>     when writing how to reproduce the problem.)
>   - Not forgetting to state changes made to various configuration
>     attributes
>   - Describing the problem's symptoms in chronological order.
>   - Describing the test environment precisely.
> 
> 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. In some bug reports I suggested to
use sosreport and attach the file then, but I didn't see that happen.
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.

> https://wiki.openstack.org/wiki/BugFilingRecommendations
> 
> > Clear recreate steps is probably #1, but also logs if there are
> > obvious failures. A stacktrace goes a long way with a clear
> > description of the failure scenario. Obviously need to know the level
> > of code being tested.
> > 
> > For a lot of bugs that are opened on n-2 releases, like kilo at this
> > point, my first question is, have you tried this on master to see if
> > it's still an issue. That's lazy on my part, but it's easy if I'm not
> > aware of a fix that just needs backporting.
> 
> I don't view it as being lazy on your part.  Other open source projects
> use a similar method -- e.g. in Fedora Project, one month after N+2
> (Fedora-24) is released, 'N' (Fedora-22) goes End-of-Life.  And, all
> bugs (that are not solved) reported against 'N' (for components with
> high bug volume) are closed, with a request to re-test them on N+2
> (latest stable release), and re-open it if the issue persists.
> Otherwise, it becomes difficult to cope with volume.

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.

> 
> -- 
> /kashyap
> 
> 
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Regards, Markus Zoeller (markus_z)