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

[Vijay Bellur]

On Thu, Jan 5, 2017 at 8:40 AM, Niels de Vos <ndevos at redhat.com> 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?
>
> 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)
> 2. enablement through a simple interface, similar to /proc/sysrq-trigger
> 3. enablement through gluster-cli command
>
> 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?
>
>
Sounds good to me. What are the additional improvements that you envision
for 3?

Thanks,
Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20170105/24027097/attachment.html>