[GEDI] [Gluster-devel] Release 3.10 feature proposal:: Statedump for libgfapi
Niels de Vos
ndevos at redhat.com
Sun Jan 15 19:55:47 UTC 2017
On Tue, Jan 10, 2017 at 12:47:11AM -0500, Poornima Gurusiddaiah wrote:
> ----- Original Message -----
> > From: "Niels de Vos" <ndevos at redhat.com>
> > To: "Shyam" <srangana at redhat.com>
> > Cc: "Rajesh Joseph" <rjoseph at redhat.com>, "Gluster Devel" <gluster-devel at gluster.org>, integration at gluster.org,
> > "Poornima G" <pgurusid at redhat.com>
> > Sent: Monday, January 9, 2017 5:05:14 PM
> > Subject: Re: [Gluster-devel] Release 3.10 feature proposal:: Statedump for libgfapi
> > On Mon, Jan 09, 2017 at 10:27:03AM +0530, Shyam wrote:
> > > On 01/05/2017 07:10 PM, Niels de Vos wrote:
> > ...
> > > > Because we would really like this in 3.10 to allow applications to
> > > > integrate better with Gluster, I propose to split the functionality over
> > > > several changes:
> > > >
> > > > 1. ground work and API exposed for applications (and testing)
> > >
> > > Poornima is working on this as a part of the patch posted at . Poornima
> > > do you want to add more details here?
> > Yes, I'm waiting for a reply rom Poornima as well. I'd like a discussion
> > about an extendible interface that is not limited to doing statedumps. I
> > do have patches for this based on her work and I want to share those in
> > the discussion.
> > > > 2. enablement through a simple interface, similar to /proc/sysrq-trigger
> > > > 3. enablement through gluster-cli command
> > >
> > > The initial implementation of triggering a statedump via the CLI already
> > > exists as a part of the patch .
> > Yes, and I am aware of that. But I also like patches to be modular and
> > have split for each single functionality. That makes it easier for
> > testing and reviewing. The current approach is a large chunk that I
> > would like to see split. Again, waiting for Poornima to join the
> > discussion.
> > > > These options should be explained in the feature page, with the plan to
> > > > provide the three options for 3.10. I'm happy to massage the patch from
> > > > Poornima  and split it in 1 and 3. Additional improvements for 3
> > > > might be needed, and we'll have to see who does that work. Point 2 is
> > > > something I'll take on as well.
> > > >
> From the methods mentioned 1, 3 are there as a part of the single patch. As you
> mentioned the api is not extendable and glusterd requires some improvements. And
> also the patch needs to be split, since you already have the patches ready, please
> go ahead. I can abandon this patch. It would be very useful if we can get either
> approach 2 or 3 for 3.10.
These three patches have now been posted:
9d2cf07 gfapi: add API to trigger events for debugging and troubleshooting
04ee658 glusterd: add a cli command to trigger a statedump on a client
bb97d92 gfapi: create statedump when glusterd requests it
I have not updated the specification at http://review.gluster.org/16357
to reflect these changes. But the end result is pretty much the same as
it was before. The questions I left in the design are still relevant and
I would appreciate an answer/expansion to them.
> > > > What do others think about this?
> > >
> > > My question thus is, where are we drawing a line for this in 3.10
> > > considering we have about a *week* left for *branching*?
> > > - Is 1, and 3 enough as it exists (i.e with the intention of exposing the
> > > API as in 1 additionally)?
> > The API does not exist (well, it was added this morning). But the API
> > needs discussion because it is not extendible. This discussion needs to
> > be had, and with the new feature page we can actually do that somewhere.
> > > - Is 2 mandatory or can come in later (i.e 3.11)?
> > It can come later, but the feature would be kess useful if this does not
> > exist. Statedumps are helpful to diagnose network/communication
> > problems, relying on the network to trigger them is probably not helpful
> > in many situations.
> > > - Is additions to 3 (i.e improvements to the gluster cli) mandatory or
> > > can
> > > come in later (i.e 3.11)?
> > I see 1 as mandatory. The other interfaces would be welcome, but need
> > discussion and approval from different component maintainers and the
> > target users.
> > HTH,
> > Niels
> > >
> > > >
> > > > Thanks,
> > > > Niels
> > > >
> > > >  http://review.gluster.org/9228
> > >  http://review.gluster.org/16357
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the integration