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

[Niels de Vos]

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

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

[http://review.gluster.org/#/q/topic:bug-1169302]


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.

Thanks,
Niels


> 
> 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
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170115/42fdf8fd/attachment.sig>