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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to