<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>