<div dir="ltr">Indeed, sorry for the distraction!<div><br></div><div>Alex</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 11:23 AM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra">
<div><div class="h5"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 11:47 AM, Clark Boylan <span dir="ltr"><<a href="mailto:clark.boylan@gmail.com" target="_blank">clark.boylan@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Tue, Aug 27, 2013 at 10:15 AM, Clint Byrum <<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>> wrote:<br>



> Excerpts from John Griffith's message of 2013-08-27 09:42:37 -0700:<br>
>> On Tue, Aug 27, 2013 at 10:26 AM, Alex Gaynor <<a href="mailto:alex.gaynor@gmail.com" target="_blank">alex.gaynor@gmail.com</a>> wrote:<br>
>><br>
>> > I wonder if there's any sort of automation we can apply to this, for<br>
>> > example having known rechecks have "signatures" and if a failure matches<br>
>> > the signature it auto applies the recheck.<br>
>> ><br>
>><br>
>> I think we kinda already have that, the recheck list and the bug ID<br>
>> assigned to it no?  Automatically scanning said list and doing the recheck<br>
>> automatically seems like overkill in my opinion.  At some point human<br>
>> though/interaction is required and I don't think it's too much to ask a<br>
>> technical contributor to simply LOOK at the output from the test runs<br>
>> against their patches and help out a bit. At the very least if you didn't<br>
>> test your patch yourself and waited for Jenkins to tell you it's broken I<br>
>> would hope that a submitter would at least be motivated to fix their own<br>
>> issue that they introduced.<br>
>><br>
><br>
> It is worth thinking about though, because "ask a technical contributor<br>
> to simply LOOK" is a lot more expensive than "let a script confirm the<br>
> failure and tack it onto the list for rechecks".<br>
><br>
> Ubuntu has something like this going for all of their users and it is<br>
> pretty impressive.<br>
><br>
> Apport and/or whoopsie see crashes and look at the<br>
> backtraces/coredumps/etc and then (with user permission) submit a<br>
> signature to the backend. It is then analyzed and the result is this:<br>
><br>
> <a href="http://errors.ubuntu.com/" target="_blank">http://errors.ubuntu.com/</a><br>
><br>
> Known false positives are shipped along side packages so that they do<br>
> not produce noise, and known points of pain for debugging are eased by<br>
> including logs and other things in bug reports when users are running<br>
> the dev release. This results in a much better metric for what bugs to<br>
> address first. IIRC update-manager also checks in with a URL that is<br>
> informed partially by this data about whether or not to update packages,<br>
> so if there is a high fail rate early on, the server side will basically<br>
> signal update-manager "don't update right now".<br>
><br>
> I'd love to see our CI system enhanced to do all of the pattern<br>
> matching to group failures by common patterns, and then when a technical<br>
> contributor looks at these groups they have tons of data points to _fix_<br>
> the problem rather than just spending their precious time identifying it.<br>
><br>
> The point of the recheck system, IMHO, isn't to make running rechecks<br>
> easier, it is to find and fix bugs.<br>
><br>
</div></div>This is definitely worth thinking about and we had a session on<br>
dealing with CI logs to do interesting things like update bugs and<br>
handle rechecks automatically at the Havana summit[0]. Since then we<br>
have built a logstash + elasticsearch system[1] that filters many of<br>
our test logs and indexes a subset of what was filtered (typically<br>
anything with a log level greater than DEBUG). Building this system is<br>
step one in being able to detect anomalous logs, update bugs, and<br>
potentially perform automatic rechecks with the appropriate bug.<br>
Progress has been somewhat slow, but the current setup should be<br>
mostly stable. If anyone is interested in poking at these tools to do<br>
interesting automation with them feel free to bug the Infra team.<br>
<br>
That said, we won't have something super automagic like that before<br>
the end of Havana making John's point an important one. If previous<br>
release feature freezes are any indication we will continue to put<br>
more pressure on the CI system as we near Havana's feature freeze. Any<br>
unneeded rechecks or reverifies can potentially slow the whole process<br>
down for everyone. We should be running as many tests as possible<br>
locally before pushing to Gerrit (this is as simple as running `tox`)<br>
and making a best effort to identify the bugs that cause failures when<br>
performing rechecks or reverifies.<br>
<br>
[0] <a href="https://etherpad.openstack.org/havana-ci-logging" target="_blank">https://etherpad.openstack.org/havana-ci-logging</a><br>
[1] <a href="http://ci.openstack.org/logstash.html" target="_blank">http://ci.openstack.org/logstash.html</a><br>
<br>
Thank you,<br>
Clark<br>
<div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></blockquote><div> </div></div></div></div><div class="gmail_default" style="font-family:'courier new',monospace">


The automation ideas are great, no argument there didn't mean to imply they weren't or discount them.  Just don't want the intent of the message to get lost in all the things we "could" do going forward.</div>


<br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>
"The people's good is the highest law." -- Cicero<br><div>GPG Key fingerprint: 125F 5C67 DFE9 4084</div></div>
</div>