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

[Rajesh Joseph]

On Mon, Dec 12, 2016 at 11:34 PM, Shyam <srangana at redhat.com> 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.
>

Make sense.

Thanks & Regards,
Rajesh