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

[Sahina Bose]

On Tue, Jan 10, 2017 at 11:17 AM, Poornima Gurusiddaiah <pgurusid at redhat.com
> 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.
>

FWIW, 3 is an acceptable solution when gluster is running hyperconverged
for the VM use case (for instance, with oVirt)


> 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
> >
> _______________________________________________
> integration mailing list
> integration at gluster.org
> http://lists.gluster.org/mailman/listinfo/integration
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/integration/attachments/20170110/7402104c/attachment-0002.html>