[GEDI] [Gluster-devel] Release 3.10 feature proposal:: Statedump for libgfapi
Niels de Vos
ndevos at redhat.com
Mon Jan 9 11:35:14 UTC 2017
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
> > 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
> > 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.
> > 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
> > 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