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

[Pranith Kumar Karampuri]

On 01/08/2016 02:08 PM, Emmanuel Dreyfus wrote:
> On Fri, Jan 08, 2016 at 11:45:20AM +0530, Pranith Kumar Karampuri wrote:
>> 1) How to set up NetBSD VMs on my laptop which is of exact version as the
>> ones that are run on build systems.
> Well, the easier way is to pick the VM image we run at rackspace, which
> relies on Xen. If you use an hardware virtualization system, we just need
> to change the kernel and use NetBSD-7.0 GENERIC one. What hypervisor
> do you use?
>
> Alternatively it is easy to make a fresh NetBSD install. The only trap
> is that glusterfs backing store filesystem must be formatted in FFFv1
> format to get extended attrbiute support (this is obtained by  newfs -O1).
>
>> 2) How to prevent NetBSD machines hang when things crash (At least I used to
>> see that the machines hang when fuse crashes before, not sure if this is
>> still the case)? (This failure needs manual intervention at the moment on
>> NetBSD regressions, if we make it report failures and pick next job that
>> would be the best way forward)
> It depends what we are talking about. If this is a moint point that does
> not want to unmount, killing the perfused daemon (which is the bridge
> between FUSE and native PUFFS) will help. The cleanup script does it.
> Do you have a hang example?

Should the cleanup script needs to be manually executed on the NetBSD 
machine?

>
>> 3) We should come up with a list of known problems and how to troubleshoot
>> those problems, when things are not going smooth in NetBSD. Again, we really
>> need to make things automatic, this should be last resort. Our top goal
>> should be to make NetBSD machines report failures and go to execute next
>> job.
> This is the frustrating point for me: we have complains that things go bad,
> but we do not have data about chat tests caused troubles. Fixing the problem
> underlying unbacked complains means we will have to gather data on our own.
>
> First step could be to parse jenkins logs and find which test fail or hang
> most often in NetBSD regression

This work is under way. I will have to change some of the scripts I 
wrote to get this information.

>
>> 4) How can we make debugging better in NetBSD? In the worst case we can make
>> all tests execute in trace/debug mode on NetBSD.
>>
>> I really want to appreciate the fine job you have done so far in making sure
>> glusterfs is stable on NetBSD.
> Thanks! I must confess the idea of having the NetBSD port demoted is a bit
> depressing given the amount of work I invested in it.
With your support I think we can make things better. To avoid 
duplication of work, did you take any tests that you are already 
investigating? If not that is the first thing I will try to find out.

Pranith