Open Stack

Hi,

I have missed the original email on this subject.
We [Fault Genes WG] have been doing some machine learning analysis on Nova bugs/issues from 3 different sources (Launchpad, Stackoverflow, ask.openstack.org). We have been able to take all the issues and bring them down to 15 clusters.
We have tried to find open source tools that can help us define the fault classifications, but have not been able to find any tool.

Therefore, our team have come to the conclusion that we need the support of some Nova experts to help define the classifications. I would like to have some discussions with Sean and others that have an interest in this area and compare notes and see how we can collaborate.

The goal of our WG is to apply the same technique to all key OpenStack projects.

Thanks,
Nemat 

-----Original Message-----
From: Emilien Macchi [mailto:emilien at redhat.com] 
Sent: Wednesday, July 05, 2017 12:24 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova] bug triage experimentation

On Fri, Jun 23, 2017 at 9:52 AM, Sean Dague <sean at dague.net> wrote:
> The Nova bug backlog is just over 800 open bugs, which while 
> historically not terrible, remains too large to be collectively usable 
> to figure out where things stand. We've had a few recent issues where 
> we just happened to discover upgrade bugs filed 4 months ago that 
> needed fixes and backports.
>
> Historically we've tried to just solve the bug backlog with volunteers.
> We've had many a brave person dive into here, and burn out after 4 - 6 
> months. And we're currently without a bug lead. Having done a big 
> giant purge in the past
> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046
> 517.html)
> I know how daunting this all can be.
>
> I don't think that people can currently solve the bug triage problem 
> at the current workload that it creates. We've got to reduce the smart 
> human part of that workload.
>
> But, I think that we can also learn some lessons from what active 
> github projects do.
>
> #1 Bot away bad states
>
> There are known bad states of bugs - In Progress with no open patch, 
> Assigned but not In Progress. We can just bot these away with scripts.
> Even better would be to react immediately on bugs like those, that 
> helps to train folks how to use our workflow. I've got some starter 
> scripts for this up at - https://github.com/sdague/nova-bug-tools
>
> #2 Use tag based workflow
>
> One lesson from github projects, is the github tracker has no workflow.
> Issues are openned or closed. Workflow has to be invented by every 
> team based on a set of tags. Sometimes that's annoying, but often 
> times it's super handy, because it allows the tracker to change 
> workflows and not try to change the meaning of things like "Confirmed 
> vs. Triaged" in your mind.
>
> We can probably tag for information we know we need at lot easier. I'm 
> considering something like
>
> * needs.system-version
> * needs.openstack-version
> * needs.logs
> * needs.subteam-feedback
> * has.system-version
> * has.openstack-version
> * has.reproduce
>
> Some of these a bot can process the text on and tell if that info was 
> provided, and comment how to provide the updated info. Some of this 
> would be human, but with official tags, it would probably help.
>
> #3 machine assisted functional tagging
>
> I'm playing around with some things that might be useful in mapping 
> new bugs into existing functional buckets like: libvirt, volumes, etc. 
> We'll see how useful it ends up being.
>
> #4 reporting on smaller slices
>
> Build some tooling to report on the status and change over time of 
> bugs under various tags. This will help visualize how we are doing
> (hopefully) and where the biggest piles of issues are.
>
> The intent is the normal unit of interaction would be one of these 
> smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36 
> vmware bugs. It would also highlight the rates of change in these 
> piles, and what's getting attention and what is not.
>
>
> This is going to be kind of an ongoing experiment, but as we currently 
> have no one spear heading bug triage, it seemed like a good time to 
> try this out.
>
> Comments and other suggestions are welcomed. The tooling will have the 
> nova flow in mind, but I'm trying to make it so it takes a project 
> name as params on all the scripts, so anyone can use it. It's a little 
> hack and slash right now to discover what the right patterns are.

I also believe that some of the scripts could be transformed into native features of Storyboard where bugs could be auto-triaged periodically without human intervention.
Maybe it would convince more OpenStack projects to leave Launchpad and adopt Storyboard?
I would certainly one of those and propose such a change for TripleO & related projects.

Thanks,

>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ______________________________________________________________________
> ____ 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



--
Emilien Macchi

__________________________________________________________________________
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