On Tue, Jan 10, 2017 at 12:47:11AM -0500, Poornima Gurusiddaiah wrote: > > ----- Original Message ----- > > From: "Niels de Vos" <ndevos@xxxxxxxxxx> > > To: "Shyam" <srangana@xxxxxxxxxx> > > Cc: "Rajesh Joseph" <rjoseph@xxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, integration@xxxxxxxxxxx, > > "Poornima G" <pgurusid@xxxxxxxxxx> > > Sent: Monday, January 9, 2017 5:05:14 PM > > Subject: Re: 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 > >
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
