[Gluster-devel] [Heketi] Kubernetes Dynamic Provisioner for Gluster/Heketi

Hi all, I was able to spend some time setting up the environment to test the Gluster/Heketi dynamic provisioner in Kubernetes. It took me a little while, but once I figure it out, I was able to start the tests. It is actually really easy to setup, so I wrote two blogs[1][2] about how I was

Re: [Gluster-devel] Changing Submit Type for glusterfs

On Tue, Sep 13, 2016 at 7:29 PM, Nigel Babu wrote: > On Fri, Sep 02, 2016 at 10:25:01AM +0530, Nigel Babu wrote: > > > > The reason cherry-pick was chosen was to keep the branch linear and > > > > avoid merge-commits as (I'm guessing here) this makes the tree hard > to > > > >

Re: [Gluster-devel] Need help with https://bugzilla.redhat.com/show_bug.cgi?id=1224180

On Tue, Sep 13, 2016 at 1:39 PM, Xavier Hernandez wrote: > Hi Sanoj, > > On 13/09/16 09:41, Sanoj Unnikrishnan wrote: > >> Hi Xavi, >> >> That explains a lot, >> I see a couple of other scenario which can lead to similar inconsistency. >> 1) simultaneous node/brick crash

Re: [Gluster-devel] [Heketi] Block store related API design discussion

Very good points. Thanks Prasanna for putting this together. I agree with your comments in that Heketi is the high level abstraction API and it should have an API similar of what is described by Prasanna. I definitely do not think any File Api should be available in Heketi, because that is an

Re: [Gluster-devel] Changing Submit Type for glusterfs

On Fri, Sep 02, 2016 at 10:25:01AM +0530, Nigel Babu wrote: > > > The reason cherry-pick was chosen was to keep the branch linear and > > > avoid merge-commits as (I'm guessing here) this makes the tree hard to > > > follow. > > > Merge-if-necessary will not keep the branch linear. I'm not sure

[Gluster-devel] Minutes from Gluster Bug Triage meeting today

Hi, Thanks all who joined! Next week at the same time (Tuesday 12:00 UTC) we will have an other bug triage meeting to catch the bugs that were not handled by developers and maintainers yet. We'll stay repeating this meeting as safety net so that bugs get the initial attention and developers can

Re: [Gluster-devel] Need help with https://bugzilla.redhat.com/show_bug.cgi?id=1224180

Hi Sanoj, On 13/09/16 09:41, Sanoj Unnikrishnan wrote: Hi Xavi, That explains a lot, I see a couple of other scenario which can lead to similar inconsistency. 1) simultaneous node/brick crash of 3 bricks. Although this is a real problem, the 3 bricks should crash exactly at the same moment

Re: [Gluster-devel] Need help with https://bugzilla.redhat.com/show_bug.cgi?id=1224180

Hi Xavi, That explains a lot, I see a couple of other scenario which can lead to similar inconsistency. 1) simultaneous node/brick crash of 3 bricks. 2) if the disk space of underlying filesystem on which brick is hosted exceeds for 3 bricks. I don't think we can address all the scenario unless

Re: [Gluster-devel] Libunwind

On Mon, Sep 12, 2016 at 09:30:32AM -0400, Jeff Darcy wrote: > I looked into this a bit over the weekend. Unfortunately, while > libunwind *does* get function names for calls in shared libraries, it > *doesn't* seem to handle calls through function pointers very well. > Imagine that original_func

Re: [Gluster-devel] Need help with https://bugzilla.redhat.com/show_bug.cgi?id=1224180

Hi Sanoj, I'm unable to see bug 1224180. Access is restricted. Not sure what is the problem exactly, but I see that quota is involved. Currently disperse doesn't play well with quota when the limit is near. The reason is that not all bricks fail at the same time with EDQUOT due to small