On 01/05/2017 07:10 PM, Niels de Vos wrote:
On Wed, Dec 14, 2016 at 11:28:43AM +0530, Rajesh Joseph wrote:
On Mon, Dec 12, 2016 at 11:34 PM, Shyam <srangana@xxxxxxxxxx> wrote:
On 12/12/2016 12:26 AM, Niels de Vos wrote:
On Fri, Dec 09, 2016 at 06:20:22PM +0530, Rajesh Joseph wrote:
Gluster should have some provision to take statedump of gfapi
applications.
https://bugzilla.redhat.com/show_bug.cgi?id=1169302
A part of this feature should be to find out how applications that use
libgfapi expect to trigger debugging like this. Doing a statedump from
the gluster-cli should not be the main/only option. I agree that it
helps developers that work on Gluster, but we can not expect users to
trigger statedumps like that.
I think there would be a huge benefit in having an option to communicate
with libgfapi through some minimal form of local IPC. It will allow
doing statedumps, and maybe even set/get configuration options for
applications that do not offer these in their usage (yet).
The communication should be as simple and stable as possible. This could
be the only working interface towards getting something done inside
gfapi (worst case scenario). There is no need to have this a full
featured interface, possibly a named pipe (fifo) where libgfapi is the
reader is sufficient. A simple (text) command written to it can create
statedumps and eventually other files on request.
Enabling/disabling or even selecting the possibilities for debugging
could be confiured through new functions in libgfapi, and even
environment variables.
What do others think? Would this be useful?
Would this be useful, yes.
Would this work in cases like a container deployment, where such debugging
maybe sought at scale, maybe not. I prefer options here, and also the
ability to drive this from the storage admin perspective, i.e the
server/brick end of things, identifying the client/connection against which
we need the statedump and get that information over.
We were thinking something on the same line. Where statedumps can be
initiated by
glusterd by an admin. The option mentioned by Niels is also helpful
but that means
we should either provide some tool or the application has to do some
amount of changes
to make use of this feature.
I guess the answer here is, this should not be the only option, but we
can/should have other options as you describe above.
I have not found a feature page for this, is there one?
There is one put up now, here [1]. jFYI, The delay for the same was due
to the patch [2] for this being up in gerrit about 2 years back when we
did not have feature page based work in this regard.
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?
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].
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.
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)?
- Is 2 mandatory or can come in later (i.e 3.11)?
- Is additions to 3 (i.e improvements to the gluster cli) mandatory
or can come in later (i.e 3.11)?
Thanks,
Niels
[0] http://review.gluster.org/9228
[1] http://review.gluster.org/16357
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
