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

There is no need to abandon your patch, I can update it with one of the
parts that I have. At the moment I need to add an other test-case for
the proposed glfs_sysrq() function. Which, btw, also needs to be
proposed to the list and added to the glusterfs-specs doc.

I plan tp have this done before the end of this week. Part 2 might be
too ambitious to have stable before 3.10 branching.

With the new CLI command, were you planning to have that supported by
other Gluster clients (FUSE, Gluster/NFS, SHD, ...) as well? It probably
would be good to mention that in [1] too.

Cheers,
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://www.gluster.org/pipermail/gluster-devel/attachments/20170110/5d2a5be8/attachment.sig>