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

[Sachidananda URS]

Pranith,

On Fri, Jan 8, 2016 at 11:45 AM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

>
>
> 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
>>
>> Would you have the jenkins build that did not complete s that I can have a
>> look at it?
>>
>> 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.
>>
>> 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.
>>
>> hi Emmanuel,
>          This Sunday I have some time I can spend helping in making tests
> better for NetBSD. I have seen bugs that are caught only by NetBSD
> regression just recently, so I see value in making NetBSD more reliable.
> Please let me know what are the things we can work on. It would help if you
> give me something specific to glusterfs to make it more valuable in the
> short term. Over time I would like to learn enough to share the load with
> you however little it may be (Please bear with me, I some times go quiet).
> Here are the initial things I would like to know to begin with:
>
> 1) How to set up NetBSD VMs on my laptop which is of exact version as the
> ones that are run on build systems.
> 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)
> 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.
> 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 have a NetBSD 7.0 installation which I can share with you, to get
started.
Once manu@ gets back on a specific version, I can set that up too.

>
>
> I really want to appreciate the fine job you have done so far in making
> sure glusterfs is stable on NetBSD.
>

+1

Let me know if I can help you in any way in fixing the tests, will be glad
to help.

-sac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160108/b9f3961d/attachment-0001.html>