[Gluster-devel] NetBSD tests not running to completion.

[Raghavendra Gowdappa]

----- Original Message -----
> From: "Ravishankar N" <ravishankar at redhat.com>
> To: "Emmanuel Dreyfus" <manu at netbsd.org>
> Cc: "gluster-infra" <gluster-infra at gluster.org>, "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Thursday, January 7, 2016 3:14:12 PM
> Subject: Re: [Gluster-devel] NetBSD tests not running to completion.
> 
> On 01/07/2016 02:39 PM, Emmanuel Dreyfus wrote:
> > On Wed, Jan 06, 2016 at 05:49:04PM +0530, Ravishankar N wrote:
> >> I re triggered NetBSD regressions for
> >> http://review.gluster.org/#/c/13041/3
> >> but they are being run in silent mode and are not completing. Can some one
> >> from the infra-team take a look? The last 22 tests in
> >> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/ have
> >> failed. Highly unlikely that something is wrong with all those patches.
> > I note your latest test compelted with an error in mount-nfs-auth.t:
> > https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13260/consoleFull
> Yes, the test that failed is "dd if=/dev/zero of=$N0/test-big-write
> count=500 bs=1024k"
> I don't know why.

Did the test fail (with an error)? or was it hung?

> > Would you have the jenkins build that did not complete s that I can have a
> > look at it?
> Unfortunately I did not save the link.
> >
> > Generally speaking, I have to pôint that NetBSD regression does show light
> > on generic bugs, we had a recent exemple with quota-nfs.t. For now there
> > are not other well supported platforms, but if you want glusterfs to
> > be really portable, removing mandatory NetBSD regression is not a good
> > idea:
> > portability bugs will crop.
> This is all IMHO:
> I am not that big a fan of portable software development at all- more
> so  for system software. Maybe it is a thing in desktop application
> development world . Even in a recent RFE on gluster-devel for
> eventing-framework I saw that systemd and dbus APIs are considered
> because they are Linux specific. To me that is a silly reason to
> reinvent the wheel. I'd rather that the software sticks to one platform
> and build on whatever the platform has to offer than attempting to run
> on all OSes.
> 
> >
> > Even a daily or weekly regression run seems a bad idea to me. If you do not
> > prevent integration of patches that break NetBSD regression, that will get
> > in, and tests will break one by one over time. I have a first hand
> > experience of this situation, when I was actually trying to catch on with
> > NetBSD regression. Many time I reached something reliable enough to become
> > mandatory, and got broken by a new patch before it became actualy
> > mandatory.
> >
> > IMO, relaxing NetBSD regression requirement means the project drops the
> > goal
> > of being portable.
> >
> It is not the failure of regressions that bother me. It is the lack of
> infrastructure to debug failures that is irritating. If Linux
> regressions fail, I can just run it in my laptop and figure things out
> .For NetBSD, I'd have to take a slave offline. Then I have to send a
> mail about it and hope that every one has seen it and does not
> accidentally use the system while I'm debugging. Then  there's this part
> where none of the bash/gdb/whatever-debugging-tools in Linux that you
> are used to will work on NetBSD. Like I pointed out in another thread,
> at least a VM image for NetBSD that I can run on my laptop would be
> beneficial to a big extent.
> 
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>