On 01/11/2016 01:00 PM, Pranith Kumar Karampuri wrote:
On 01/09/2016 12:34 AM, Vijay Bellur wrote:
On 01/08/2016 08:18 AM, Jeff Darcy wrote:
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, ex
On 01/09/2016 12:34 AM, Vijay Bellur wrote:
On 01/08/2016 08:18 AM, Jeff Darcy wrote:
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
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/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
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/
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
- Original Message -
> From: "Ravishankar N"
> To: "Emmanuel Dreyfus"
> Cc: "gluster-infra" , "Gluster Devel"
>
> Sent: Thursday, January 7, 2016 3:14:12 PM
> Subject: Re: [Gluster-devel] NetBSD tests not running to completion.
>
> On 01/07/2016 02:39 PM, Emmanuel Dreyfus wrote:
> >
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
On 01/08/2016 08:18 AM, Jeff Darcy wrote:
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/acc
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
- 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-devel] NetBSD tests not running to completion.
> On 01/07/2016 02:39 PM, Emm
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
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
> > Good idea. Once per merge is still less than one per submission (what
> > we have today), and better than nightly/weekly when it comes to
> > identifying the source of a regression. Seems like a good compromise.
>
> Now what is the policy on post-merge regression failure? What happens
> if
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 03:15 PM, Jeff Darcy wrote:
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.
On the other hand, if patch A starts blocking all merges because of
NetBSD failures, then all platforms - including Ne
> 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.
On the other hand, if patch A starts blocking all merges because of
NetBSD fai
On Thu, Jan 07, 2016 at 03:01:41PM +0530, Avra Sengupta wrote:
> Why is this a bad idea?
Because each week you will have multiple regressins introduced. Few
people will be willing to investigate wether they pushed a patch that
caused a regression, and that few people will have to deal the others
t; From: "Avra Sengupta"
> > To: "Gluster Devel" , "gluster-infra"
> >
> > Sent: Thursday, January 7, 2016 11:51:51 AM
> > Subject: Re: [Gluster-infra] [Gluster-devel] NetBSD tests not running to
> > completion.
> >
> > T
ed
us *multiple* times now.
Thanks,
Atin
On 01/07/2016 12:38 PM, Joseph Fernandes wrote:
> +2 Avra
>
> - Original Message -
> From: "Avra Sengupta"
> To: "Gluster Devel" , "gluster-infra"
>
> Sent: Thursday, January 7, 2016 11:51:51 AM
> Su
42 matches
Mail list logo
