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

[Shyam]

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 at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>