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

[Shyam]

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 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.
>
> 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