Re: Release 3.10 feature proposal:: Statedump for libgfapi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

I guess the answer here is, this should not be the only option, but we can/should have other options as you describe above.


Thanks,
Niels



_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux