<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1" bgcolor="#FFFFFF">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi,<br>
<br>
Sorry for the slow reply, I'm currently on vacation.<br>
<br>
I think we should include the infra mailing list on this discussion so I've cc'd them here. If it's off topic we can take this off list again, however I feel like we may be duplicating efforts at the moment.<br>
<br>
Re people not using zuul, the brainstormed idea from the infra team during the summit was to have a generic rest endpoint that can take results (and then do stats/graphs etc). Zuul would post to this endpoint as a reporter, but there would be nothing stopping
others from implementing their own report posts.<br>
<br>
Anyway there looks like there is good discussion on the etherpad.<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF393003"><font size="2" color="#000000" face="Tahoma"><b>From:</b> Steve Weston [steve.weston@triniplex.com]<br>
<b>Sent:</b> Sunday, November 09, 2014 7:00 AM<br>
<b>To:</b> Duncan Thomas; Joshua Hesketh<br>
<b>Cc:</b> lyz@princessleia.com; mriedem@linux.vnet.ibm.com; Kurt Taylor; Anita Kuno<br>
<b>Subject:</b> Re: [third-party] CI Monitoring Tool<br>
</font><br>
</div>
<div></div>
<div>
<div class="moz-cite-prefix">The etherpad has been created <a class="moz-txt-link-freetext" href="https://etherpad.openstack.org/p/Third-Party-CI-Dashboard-InitialPlanning" target="_blank">
https://etherpad.openstack.org/p/Third-Party-CI-Dashboard-InitialPlanning</a><br>
<br>
I have included my input on introducing a calibration service which the CI systems would use before running a patchset. The idea is this: each project would define one or more jobs which the CI system would run to make sure it is working correctly, and in
synchronization with Jenkins, before reporting an errant result. <br>
<br>
I believe that this would greatly improve the stability of CI and allow problems to be fixed before the CI system runs the patch.<br>
<br>
Thoughts, comments, and input are welcome!<br>
<br>
Thanks,<br>
Steve<br>
<br>
On 11/7/14 7:58 PM, Steve Weston wrote:<br>
</div>
<blockquote type="cite">
<div class="moz-cite-prefix">I have already begun work on the code for this project, and yesterday I did write a small bit of code which implements a REST API in the Django REST framework. Although my plan was to expose the data collected by the dashboard
to other services, this framework can be modified to additionally be used to act as sort of a check-in service as Josh wrote about below.<br>
<br>
Tomorrow I will create an etherpad so that folks may start listing out their ideas for how this dashboard will work. I will send out a link once I have it.<br>
<br>
Thanks,<br>
Steve<br>
<br>
On 11/7/14 7:53 PM, Steve Weston wrote:<br>
</div>
<blockquote type="cite">
<div class="moz-cite-prefix">+ Anita <br>
<br>
On 11/7/14 5:34 PM, Duncan Thomas wrote:<br>
</div>
<blockquote type="cite">
<p>So it is worth noting that not every third party ci is using Zuul. I think scraping gerrit (even into a db to run queries about) is a better way forward than adding something else to the ci requirements</p>
<p>Duncan Thomas</p>
<div class="gmail_quote">On Nov 7, 2014 4:41 PM, "Joshua Hesketh" <<a href="mailto:joshua.hesketh@rackspace.com" target="_blank">joshua.hesketh@rackspace.com</a>> wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex; border-left:1px #ccc solid; padding-left:1ex">
Hi Kurt,<br>
<br>
Thanks for kicking this conversation off. I wonder if the -infra list would be a good place to include more.<br>
<br>
So I believe, although we're still brainstorming etc, the vague infra plan is to have a dashboard service with API endpoints that a zuul reporter can talk to. Then all 1st + 3rd parties would report to that and therefore have a dashboard populated and statistics
generated etc.<br>
<br>
So that's kind of the long term plan that will give us some more useful data we can dive into. However, for the moment I think having a simple gerrit-bot-status dashboard (as you have described) will at least help in terms of assessing the health of the systems.<br>
<br>
I don't think anybody in particular is working on radar so we could probably consume that repository. We should get Michael Still's okay first though (since he's the original author).<br>
<br>
Cheers,<br>
Josh<br>
________________________________________<br>
From: Kurt Taylor [<a href="mailto:kurt.r.taylor@gmail.com" target="_blank">kurt.r.taylor@gmail.com</a>]<br>
Sent: Saturday, November 08, 2014 1:06 AM<br>
To: <a href="mailto:lyz@princessleia.com" target="_blank">lyz@princessleia.com</a>; Joshua Hesketh;
<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>;
<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>;
<a href="mailto:steve.weston@triniplex.com" target="_blank">steve.weston@triniplex.com</a><br>
Subject: [third-party] CI Monitoring Tool<br>
<br>
In the third-party summit session, we discussed the need for CI<br>
systems to have a status dashboard [1]. However, it seems that there<br>
are multiple people writing a CI monitoring tool, let's level set:<br>
<br>
- Josh has written a gerrit event gatherer [2]<br>
- Duncan has too<br>
- Steve has too (I have not yet talked to Steve)<br>
- Radar has a command line scraper, we can remove and just use radar<br>
gauges with one of the api backends above, fairly simple [3]<br>
- Nova also discussed CI monitoring and status reporting [4]. Matt<br>
owns? a requirement for Nova to implement CI monitoring (I have not<br>
yet talked to Matt)<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/kilo-third-party-items" target="_blank">
https://etherpad.openstack.org/p/kilo-third-party-items</a><br>
[2] <a href="https://github.com/stackforge/turbo-hipster/blob/master/tools/zuul_enqueue.py" target="_blank">
https://github.com/stackforge/turbo-hipster/blob/master/tools/zuul_enqueue.py</a><br>
[3] <a href="https://github.com/rcbau/radar/blob/master/report.py" target="_blank">
https://github.com/rcbau/radar/blob/master/report.py</a><br>
[4] <a href="https://etherpad.openstack.org/p/nova-ci-status-checkpoint-kilo" target="_blank">
https://etherpad.openstack.org/p/nova-ci-status-checkpoint-kilo</a><br>
<br>
>From conversations with Josh and Duncan, we believe that a good<br>
initial plan is to diff a patch with what Jenkins reported, if failed<br>
and different, collect 5? (or 3?) failures then re-queue a last known<br>
successful patch run. If that fails, the CI system is not working<br>
properly. I believe that covers 95% maybe higher of scenarios.<br>
<br>
I like Josh's idea to just have a browser page refresh kick of a<br>
sample collection and report via radar guages. Start simple, then we<br>
could ask infra to have cron fire off gathering once every 20 minutes<br>
or so, then maybe push this data to a database, and so on.<br>
<br>
So, the question is, do we create a new github repo for a new tool?<br>
reuse Radar repo? Let's get skeleton code somewhere (no preference)<br>
and the we can get more involvement and figure out where this should<br>
live. We should create a spec in openstack-infra. If we agree, I'll<br>
be happy to shepherd that.<br>
<br>
Comments?<br>
<br>
Kurt Taylor (krtaylor)<br>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</body>
</html>