Emmanuel Dreyfus wrote:
> While trying to reproduce the problem in
> ./tests/basic/afr/arbiter-statfs.t, I came to many failures here:
>
> [03:53:07] ./tests/basic/afr/split-brain-resolution.t
I was running tests from wrong directory :-/
This one is fine with HEAD.
--
Emmanuel Dreyfus
http:/
Pranith Kumar Karampuri wrote:
> I tried to look into 3 instances of this failure:
(...)
> same issue as above, two tests are running in parallel.
How is it possible? A & that sends a job in the background?
Are we sure it is the same regression test run? Or is it two regression
test runs that ar
On 01/10/2016 02:04 PM, Pranith Kumar Karampuri wrote:
On 01/10/2016 11:08 AM, Emmanuel Dreyfus wrote:
Pranith Kumar Karampuri wrote:
tests/basic/afr/arbiter-statfs.t
I posted patches to fix this one (but it seems Jenkins is down? No
regression is running)
tests/basic/afr/self-heal.t
I
On 01/10/2016 11:08 AM, Emmanuel Dreyfus wrote:
Pranith Kumar Karampuri wrote:
tests/basic/afr/arbiter-statfs.t
I posted patches to fix this one (but it seems Jenkins is down? No
regression is running)
tests/basic/afr/self-heal.t
It seems like in this run, self-heal.t and quota.t are runn
Pranith Kumar Karampuri wrote:
> tests/basic/afr/arbiter-statfs.t
I posted patches to fix this one (but it seems Jenkins is down? No
regression is running)
> tests/basic/afr/self-heal.t
> tests/basic/afr/entry-self-heal.t
That two ones are still to be investigated, and it seems
tests/basic/afr
Pranith Kumar Karampuri wrote:
> 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.
While trying to reproduce the problem in
./tests/basic/afr/a
Emmanuel Dreyfus wrote:
> > 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.
>
> I will look at the ./tests/basic/afr/arbiter-statfs.t probl
Ravishankar N wrote:
> It failed with EIO.
>
> mount_nfs: can't access /patchy: Permission denied
> mount_nfs: can't access /patchy: Permission denied
> mount_nfs: can't access /patchy: Permission denied
> dd: /mnt/nfs/0/test-big-write: Input/output error
I suspect the EIO is just a consequence
On Fri, Jan 08, 2016 at 09:57:01PM +0530, Pranith Kumar Karampuri wrote:
> >Next step is to look for loopback devices which backing store are in $B0
> >and unconfigure them.
> Oops, wrong code reading. Is it possible to have loopback devices not in
> use, that we miss out on destroying? Could be a
On 01/08/2016 08:50 PM, Emmanuel Dreyfus wrote:
On Fri, Jan 08, 2016 at 08:37:16PM +0530, Pranith Kumar Karampuri wrote:
NetBSD)
vnd=`vnconfig -l | \
awk '!/not in use/{printf("%s%s:%d ", $1, $2, $5);}'`
Can there be Loopback devices that are in
On Fri, Jan 08, 2016 at 08:37:16PM +0530, Pranith Kumar Karampuri wrote:
> NetBSD)
> vnd=`vnconfig -l | \
> awk '!/not in use/{printf("%s%s:%d ", $1, $2, $5);}'`
>
> Can there be Loopback devices that are in use when this piece of the code is
> executed
On 01/08/2016 08:14 PM, Emmanuel Dreyfus wrote:
On Fri, Jan 08, 2016 at 10:56:22AM +, Emmanuel Dreyfus wrote:
On Fri, Jan 08, 2016 at 03:18:02PM +0530, Pranith Kumar Karampuri wrote:
With your support I think we can make things better. To avoid duplication of
work, did you take any tests
On Fri, Jan 08, 2016 at 10:56:22AM +, Emmanuel Dreyfus wrote:
> On Fri, Jan 08, 2016 at 03:18:02PM +0530, Pranith Kumar Karampuri wrote:
> > 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 t
> I think we just need to come up with rules for considering a
> platform to have voting ability before merging the patch.
I totally agree, except for the "just" part. ;) IMO a platform is much
like a feature in terms of requiring commitment/accountability,
community agreement on cost/b
Does it seems reasonable? That way nothing can hang more than 2 hours.
That addresses the technical issue of hanging tests. It doesn't address
the process issue of the entire project and development team being held
hostage to one feature.
Guys,
I think we just need to come up with ru
On Fri, Jan 08, 2016 at 03:18:02PM +0530, Pranith Kumar Karampuri wrote:
> 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.
I will look at the ./t
On 01/08/2016 03:25 PM, Emmanuel Dreyfus wrote:
On Fri, Jan 08, 2016 at 03:18:02PM +0530, Pranith Kumar Karampuri wrote:
Should the cleanup script needs to be manually executed on the NetBSD
machine?
You can run the script manually, but if the goal is to restore a
misbehaving machine, rebooti
- Original Message -
> On Fri, Jan 08, 2016 at 05:11:22AM -0500, Jeff Darcy wrote:
> > [08:45:57] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:43:03] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:40:06] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:08:51] ./tests/basic/afr/arbiter-statfs
On 01/08/2016 03:57 PM, Emmanuel Dreyfus wrote:
On Fri, Jan 08, 2016 at 05:11:22AM -0500, Jeff Darcy wrote:
[08:45:57] ./tests/basic/afr/arbiter-statfs.t ..
[08:43:03] ./tests/basic/afr/arbiter-statfs.t ..
[08:40:06] ./tests/basic/afr/arbiter-statfs.t ..
[08:08:51] ./tests/basic/afr/arbiter-stat
On Fri, Jan 08, 2016 at 05:11:22AM -0500, Jeff Darcy wrote:
> [08:45:57] ./tests/basic/afr/arbiter-statfs.t ..
> [08:43:03] ./tests/basic/afr/arbiter-statfs.t ..
> [08:40:06] ./tests/basic/afr/arbiter-statfs.t ..
> [08:08:51] ./tests/basic/afr/arbiter-statfs.t ..
> [08:06:44] ./tests/basic/afr/
> I am a bit disturbed by the fact that people raise the
> "NetBSD regression ruins my life" issue without doing the work of
> listing the actual issues encountered.
That's because it's not a simple list of persistent issues. As with
spurious regression-test failures on Linux, it's an ever changi
On Fri, Jan 08, 2016 at 03:18:02PM +0530, Pranith Kumar Karampuri wrote:
> Should the cleanup script needs to be manually executed on the NetBSD
> machine?
You can run the script manually, but if the goal is to restore a
misbehaving machine, rebooting is probbaly the fastest way to sort
the issu
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 rackspa
On Fri, Jan 08, 2016 at 12:42:36PM +0530, Sachidananda URS wrote:
> 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.
NetBSD 7.0 is fine and has everything required in GENERIC kernel.
--
Emmanuel Dr
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 v
Pranith,
On Fri, Jan 8, 2016 at 11:45 AM, Pranith Kumar Karampuri <
pkara...@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/
- Original Message -
> From: "Pranith Kumar Karampuri"
> To: "Emmanuel Dreyfus" , "Ravishankar N"
>
> Cc: "Gluster Devel" , "gluster-infra"
>
> Sent: Friday, January 8, 2016 11:45:20 AM
> Subject: Re: [Gluster-d
> 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 in
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?
Ravishankar N wrote:
> > I am a bit disturbed by the fact that people raise the
> > "NetBSD regression ruins my life" issue without doing the work of
> > listing the actual issues encountered.
> I already did earlier- the lack of infrastructure to even find out what
> caused the issue in the firs
On 01/08/2016 09:57 AM, Emmanuel Dreyfus wrote:
I am a bit disturbed by the fact that people raise the
"NetBSD regression ruins my life" issue without doing the work of
listing the actual issues encountered.
I already did earlier- the lack of infrastructure to even find out what
caused the issue
Jeff Darcy wrote:
> > Now what is the policy on post-merge regression failure? What happens
> > if original submitter is now willing to investigate?
>
> Then regressions will continue to fail on NetBSD, as they do now, but
> without impacting work on other platforms.
Well from previous experi
> How are you going to make a serious issue a blocker?
We can turn off the "merge" button at any time, by either technical or
social means. The "how" is easy; it's the "when" that's fraught with
controversy.
> If we go that way, we need to run a regression for each merged patch,
> which will be
Avra Sengupta wrote:
> Agree with your point. If we are ready to make exceptions, then we might
> as well not block all the patches. As Jeff suggested, triaging the
> nightly/weekly results manually and making any serious issues a blocker
> should suffice.
How are you going to make a serious i
On 01/07/2016 07:24 PM, Jeff Darcy wrote:
I'd prefer a "defined level of effort" approach which *might* reduce the
benefit we derive from NetBSD testing but *definitely* keeps the cost
under control.
Did we identify the worst offenders within the spurious failing tests?
We could ignore their out
Jeff Darcy wrote:
> I'd prefer a "defined level of effort" approach which *might* reduce the
> benefit we derive from NetBSD testing but *definitely* keeps the cost
> under control.
Did we identify the worst offenders within the spurious failing tests?
We could ignore their output on NetBSD (thi
On 01/07/2016 03:52 PM, Raghavendra Gowdappa wrote:
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?
It failed with EIO.
mount_nfs: can't access /patchy: Permission denied
mount_nfs:
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
38 matches
Mail list logo