On Tue, Jan 10, 2017 at 11:17 AM, Poornima Gurusiddaiah <pgurusid@xxxxxxxxxx> wrote:
FWIW, 3 is an acceptable solution when gluster is running hyperconverged for the VM use case (for instance, with oVirt)
From the methods mentioned 1, 3 are there as a part of the single patch. As you
----- 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.
> > >
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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/integration
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
