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

[Ravishankar N]

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