[GEDI] [Gluster-devel] Release 3.10 feature proposal:: Statedump for libgfapi

[Poornima Gurusiddaiah]

----- 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 [0]. 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 [0].
> 
> 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 [0] 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.

Thanks,
Poornima

> > > 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
> > > 
> > > [0] http://review.gluster.org/9228
> > [1] http://review.gluster.org/16357
>