hi,
I see that NetBSD regressions are passing but not able to give +1
because of following problem:
+ ssh 'nb7bu...@review.gluster.org' gerrit review --message
''\''http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/7046/consoleFull
: SUCCESS'\''' --project=glusterfs --code
The tests have failed because self-heal daemon is not running. Though
volume start has succeed, shd has not been spawned.There is no
glustershd.log in the archived log. Not sure what the problem is.
The corresponding lines in the test case are :
On 06/19/2015 10:37 AM, Atin Mukherjee wrote:
It failed for my patch as well.
http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/7043/consoleFull
Thanks and Regards,
Kotresh H R
- Original Message -
> From: "Atin Mukherjee"
> To: "Nithya Balachandran"
> Cc: "Gluster Devel"
> Sent: Friday, June 19, 2015 10:05:49 A
Above test case failed in
http://build.gluster.org/job/rackspace-regression-2GB-triggered/11043/consoleFull
--
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
Emmanuel Dreyfus wrote:
> This means the dd process getting stuck in tstile because glusterfsd
> died is probably a NetBSD kernel bug. I have to investigate.
I think I found the culprit, but fixing this will need some discussions
on NetBSD lists:
dd waits on a vnode lock owned by the ioflush k
One of my patch failed NetBSD regression [1] in the test case mentioned
in $Subject.
[1]
http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/7025/consoleFull
--
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gl
Emmanuel Dreyfus wrote:
> > We again hit this problem [1]. Can we use soft mount with some retries and
> > timeouts so that we don't need manual intervention to recover a hung VM?
>
> Um, looking at the current test scripts, we already do it.
A side note: It seems the hung case is always with
Vijay Bellur wrote:
> We again hit this problem [1]. Can we use soft mount with some retries and
> timeouts so that we don't need manual intervention to recover a hung VM?
Um, looking at the current test scripts, we already do it. In
tests/nfs.rc, both for Linux and NetBSD:
opt="soft,int
Vijay Bellur wrote:
> I did dare just now and have rebooted Jenkins :). Let us see how this
> iteration works out.
Excellent! That fixed the Jenkins resolution problem, and we now have 10
NetBSD slave VM online.
So we have two problems and their fixes available, for adding new VM:
- Weak upstr
On Thursday 18 June 2015 02:52 PM, Emmanuel Dreyfus wrote:
Justin Clift wrote:
If the DNS problem does turn out to be the dodgy iWeb hardware firewall,
then this fixes the DNS issue. (if not... well damn!)
The DNS problem was worked around by installing a /etc/hosts, but
jenkins does not rea
Justin Clift wrote:
> If the DNS problem does turn out to be the dodgy iWeb hardware firewall,
> then this fixes the DNS issue. (if not... well damn!)
The DNS problem was worked around by installing a /etc/hosts, but
jenkins does not realize it is there. It should probably be restarted,
but nobo
Hi Jay! I have comments below:
- Original Message -
From: "Jay Vyas"
To: "Joseph Fernandes"
Cc: "John Spray" , "Gluster Devel"
Sent: Thursday, June 18, 2015 9:33:12 AM
Subject: Re: [Gluster-devel] Introducing Heketi: Storage Management
Framework with Plugins for GlusterFS volumes
On 18 Jun 2015, at 16:57, Emmanuel Dreyfus wrote:
> Niels de Vos wrote:
>
>> I'm not sure what limitation you mean. Did we reach the limit of slaves
>> that Jenkins can reasonably address?
>
> No I mean its inability to catch a new DNS record.
Priority wise, my suggestion would be to first get
Vijay Bellur wrote:
> We again hit this problem [1]. Can we use soft mount with some retries
> and timeouts so that we don't need manual intervention to recover a hung VM?
Sure, but while there, I advise soft and interruptible mount (On NetBSD,
either mount -o soft,intr or mount -i -s)
--
Emm
Le jeudi 18 juin 2015 à 17:57 +0200, Emmanuel Dreyfus a écrit :
> Niels de Vos wrote:
>
> > I'm not sure what limitation you mean. Did we reach the limit of slaves
> > that Jenkins can reasonably address?
>
> No I mean its inability to catch a new DNS record.
It might be a glibc limitation and/
Niels de Vos wrote:
> I'm not sure what limitation you mean. Did we reach the limit of slaves
> that Jenkins can reasonably address?
No I mean its inability to catch a new DNS record.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
___
On Thu, Jun 18, 2015 at 12:29:14PM +, Emmanuel Dreyfus wrote:
> On Thu, Jun 18, 2015 at 10:19:27AM +0200, Niels de Vos wrote:
> > Good to know, but it would be much more helpful if someone could install
> > VMs there and add them to the Jenkins instance... Who can do that, or
> > who can guide
On Tuesday 16 June 2015 02:19 AM, Emmanuel Dreyfus wrote:
Rajesh Joseph wrote:
Correct me if I am wrong, but I think interruptible is good with hard
mount. Which is good in real deployment scenario. Since we are talking
about test scripts, I thought soft mount along with timeout period can be
Thanks for annoying letting us know about this so early on; I don't fully
understand the plugin functionality So I have some general questions. But
am very interested in this.
0) I notice it's largely written in go,compared to the gluster ecosystem which
is mostly Python and C. Any reaso
Agreed we need not be depended ONE technology for the above.
But LVM is a strong contender as a single stable underlying technology that
provides the following.
We can make it plugin based :) . So that ppl who have LVM and are happy with it
can use it.
And we still can have other technology plugi
On Thu, Jun 18, 2015 at 10:19:27AM +0200, Niels de Vos wrote:
> Good to know, but it would be much more helpful if someone could install
> VMs there and add them to the Jenkins instance... Who can do that, or
> who can guide someone else to get it done?
How will that help, since we are having pro
On Thu, Jun 18, 2015 at 1:50 AM, Niels de Vos wrote:
> On Mon, Jun 15, 2015 at 04:19:14PM +0530, Kaushal M wrote:
>> Hi all,
> ...
>> I propose that we move back to the old model of starting regression
>> runs only once the maintainers are ready to merge. But instead of the
>> maintainers manually
> LVM or Volume Manager Dependencies:
> 1) SNAPSHOTS: Gluster snapshots are LVM based
The current implementation is LVM-centric, which is one reason uptake has
been so low. The intent was always to make it more generic, so that other
mechanisms could be used as well.
> 2) PROVISIONING and ENFORC
LVM or Volume Manager Dependencies:
1) SNAPSHOTS: Gluster snapshots are LVM based
2) PROVISIONING and ENFORCEMENT:
As of today Gluster does not have any control on the size of the brick. It will
consume the brick (xfs)mount point given
to it without checking on how much it needs to consume. LVM (
Le jeudi 18 juin 2015 à 10:19 +0200, Niels de Vos a écrit :
> On Thu, Jun 18, 2015 at 12:57:05AM +0100, Justin Clift wrote:
> > On 17 Jun 2015, at 20:14, Niels de Vos wrote:
> > > On Wed, Jun 17, 2015 at 03:14:31PM +0200, Michael Scherer wrote:
> > >> Le mercredi 17 juin 2015 à 11:58 +0100, Justin
On Mon, Jun 15, 2015 at 02:20:57PM +, Emmanuel Dreyfus wrote:
> On Mon, Jun 15, 2015 at 10:09:33AM -0400, Jeff Darcy wrote:
> > As long as there's some visible marking on the summary pages to
> > distinguish patches that have passed smoke vs. those that haven't, I
> > think we're good.
>
> ger
On 18 Jun 2015, at 09:19, Niels de Vos wrote:
> On Thu, Jun 18, 2015 at 12:57:05AM +0100, Justin Clift wrote:
>> On 17 Jun 2015, at 20:14, Niels de Vos wrote:
>>> On Wed, Jun 17, 2015 at 03:14:31PM +0200, Michael Scherer wrote:
Le mercredi 17 juin 2015 à 11:58 +0100, Justin Clift a écrit :
>
On Thu, Jun 18, 2015 at 12:57:05AM +0100, Justin Clift wrote:
> On 17 Jun 2015, at 20:14, Niels de Vos wrote:
> > On Wed, Jun 17, 2015 at 03:14:31PM +0200, Michael Scherer wrote:
> >> Le mercredi 17 juin 2015 à 11:58 +0100, Justin Clift a écrit :
> >>> On 17 Jun 2015, at 10:53, Michael Scherer wr
On Thu, Jun 18, 2015 at 12:10:47PM +0530, Kaushal M wrote:
> On Thu, Jun 18, 2015 at 1:17 AM, Niels de Vos wrote:
> > On Wed, Jun 17, 2015 at 04:26:13PM +0530, Raghavendra Talur wrote:
> >> Hi,
> >>
> >>
> >> MSV Bhat and I had presented in Gluster Design Summit some ideas about
> >> improving our
On Thu, Jun 18, 2015 at 12:12:06PM +0530, Kaushal M wrote:
> On Thu, Jun 18, 2015 at 10:26 AM, Kotresh Hiremath Ravishankar
> wrote:
> > Hi All,
> >
> > Another thing to be considered is every patch automatically triggers
> > regressions.
> > It is very unlikely that, the very Patch Set 1 submitt
30 matches
Mail list logo