<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Pranith Kumar Karampuri" <pkarampu@redhat.com><br><b>To: </b>"Emmanuel Dreyfus" <manu@netbsd.org>, "Ravishankar N" <ravishankar@redhat.com><br><b>Cc: </b>"Gluster Devel" <gluster-devel@gluster.org>, "gluster-infra" <gluster-infra@gluster.org><br><b>Sent: </b>Friday, January 8, 2016 11:45:20 AM<br><b>Subject: </b>Re: [Gluster-devel] NetBSD tests not running to completion.<br><div><br></div><br><div><br></div>On 01/07/2016 02:39 PM, Emmanuel Dreyfus wrote:<br>> On Wed, Jan 06, 2016 at 05:49:04PM +0530, Ravishankar N wrote:<br>>> I re triggered NetBSD regressions for http://review.gluster.org/#/c/13041/3<br>>> but they are being run in silent mode and are not completing. Can some one<br>>> from the infra-team take a look? The last 22 tests in<br>>> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/ have<br>>> failed. Highly unlikely that something is wrong with all those patches.<br>> I note your latest test compelted with an error in mount-nfs-auth.t:<br>> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13260/consoleFull<br>><br>> Would you have the jenkins build that did not complete s that I can have a<br>> look at it?<br>><br>> Generally speaking, I have to pôint that NetBSD regression does show light<br>> on generic bugs, we had a recent exemple with quota-nfs.t. For now there<br>> are not other well supported platforms, but if you want glusterfs to<br>> be really portable, removing mandatory NetBSD regression is not a good idea:<br>> portability bugs will crop.<br>><br>> Even a daily or weekly regression run seems a bad idea to me. If you do not<br>> prevent integration of patches that break NetBSD regression, that will get<br>> in, and tests will break one by one over time. I have a first hand<br>> experience of this situation, when I was actually trying to catch on with<br>> NetBSD regression. Many time I reached something reliable enough to become<br>> mandatory, and got broken by a new patch before it became actualy mandatory.<br>><br>> IMO, relaxing NetBSD regression requirement means the project drops the goal<br>> of being portable.<br>><br>hi Emmanuel,<br> This Sunday I have some time I can spend helping in making <br>tests better for NetBSD. I have seen bugs that are caught only by NetBSD <br>regression just recently, so I see value in making NetBSD more reliable. <br>Please let me know what are the things we can work on. It would help if <br>you give me something specific to glusterfs to make it more valuable in <br>the short term. Over time I would like to learn enough to share the load <br>with you however little it may be (Please bear with me, I some times go <br>quiet). Here are the initial things I would like to know to begin with:</blockquote><div><br></div><div>Please count me in too!<br></div><div><br></div><div>-Krutika<br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><div><br></div>1) How to set up NetBSD VMs on my laptop which is of exact version as <br>the ones that are run on build systems.<br>2) How to prevent NetBSD machines hang when things crash (At least I <br>used to see that the machines hang when fuse crashes before, not sure if <br>this is still the case)? (This failure needs manual intervention at the <br>moment on NetBSD regressions, if we make it report failures and pick <br>next job that would be the best way forward)<br>3) We should come up with a list of known problems and how to <br>troubleshoot those problems, when things are not going smooth in NetBSD. <br>Again, we really need to make things automatic, this should be last <br>resort. Our top goal should be to make NetBSD machines report failures <br>and go to execute next job.<br>4) How can we make debugging better in NetBSD? In the worst case we can <br>make all tests execute in trace/debug mode on NetBSD.<br><div><br></div>I really want to appreciate the fine job you have done so far in making <br>sure glusterfs is stable on NetBSD.<br><div><br></div>Infra team,<br> I think we need to make some improvements to our infra. We need <br>to get information about health of linux, NetBSD regression builds.<br>1) Something like, in the last 100 builds how many builds succeeded on <br>Linux, how many succeeded on NetBSD.<br>2) What are the tests that failed in the last 100 builds and how many <br>times on both Linux and NetBSD. (I actually wrote this part in some <br>parts, but the whole command output has changed making my scripts stale)<br>Any other ideas you guys have?<br>3) Which components have highest number of spurious failures.<br>4) How many builds did not complete/manually aborted etc.<br><div><br></div>Once we start measuring these things, next steps are to setup a process <br>in place to get the health of the project stable and keep it that way.<br><div><br></div>Please let me know if anyone wants to volunteer to make things better in <br>this infra part. Most of the code will be in python.<br><div><br></div>Pranith<br>_______________________________________________<br>Gluster-devel mailing list<br>Gluster-devel@gluster.org<br>http://www.gluster.org/mailman/listinfo/gluster-devel<br></blockquote><div><br></div></div></body></html>