<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 5, 2017 at 8:40 AM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Dec 14, 2016 at 11:28:43AM +0530, Rajesh Joseph wrote:<br>
> On Mon, Dec 12, 2016 at 11:34 PM, Shyam <<a href="mailto:srangana@redhat.com">srangana@redhat.com</a>> wrote:<br>
> > On 12/12/2016 12:26 AM, Niels de Vos wrote:<br>
> >><br>
> >> On Fri, Dec 09, 2016 at 06:20:22PM +0530, Rajesh Joseph wrote:<br>
> >>><br>
> >>> Gluster should have some provision to take statedump of gfapi<br>
> >>> applications.<br>
> >>><br>
> >>> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1169302" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1169302</a><br>
> >><br>
> >><br>
> >> A part of this feature should be to find out how applications that use<br>
> >> libgfapi expect to trigger debugging like this. Doing a statedump from<br>
> >> the gluster-cli should not be the main/only option. I agree that it<br>
> >> helps developers that work on Gluster, but we can not expect users to<br>
> >> trigger statedumps like that.<br>
> >><br>
> >> I think there would be a huge benefit in having an option to communicate<br>
> >> with libgfapi through some minimal form of local IPC. It will allow<br>
> >> doing statedumps, and maybe even set/get configuration options for<br>
> >> applications that do not offer these in their usage (yet).<br>
> >><br>
> >> The communication should be as simple and stable as possible. This could<br>
> >> be the only working interface towards getting something done inside<br>
> >> gfapi (worst case scenario). There is no need to have this a full<br>
> >> featured interface, possibly a named pipe (fifo) where libgfapi is the<br>
> >> reader is sufficient. A simple (text) command written to it can create<br>
> >> statedumps and eventually other files on request.<br>
> >><br>
> >> Enabling/disabling or even selecting the possibilities for debugging<br>
> >> could be confiured through new functions in libgfapi, and even<br>
> >> environment variables.<br>
> >><br>
> >> What do others think? Would this be useful?<br>
> ><br>
> ><br>
> > Would this be useful, yes.<br>
> ><br>
> > Would this work in cases like a container deployment, where such debugging<br>
> > maybe sought at scale, maybe not. I prefer options here, and also the<br>
> > ability to drive this from the storage admin perspective, i.e the<br>
> > server/brick end of things, identifying the client/connection against which<br>
> > we need the statedump and get that information over.<br>
> ><br>
><br>
> We were thinking something on the same line. Where statedumps can be<br>
> initiated by<br>
> glusterd by an admin. The option mentioned by Niels is also helpful<br>
> but that means<br>
> we should either provide some tool or the application has to do some<br>
> amount of changes<br>
> to make use of this feature.<br>
><br>
> > I guess the answer here is, this should not be the only option, but we<br>
> > can/should have other options as you describe above.<br>
<br>
</div></div>I have not found a feature page for this, is there one?<br>
<br>
Because we would really like this in 3.10 to allow applications to<br>
integrate better with Gluster, I propose to split the functionality over<br>
several changes:<br>
<br>
1. ground work and API exposed for applications (and testing)<br>
2. enablement through a simple interface, similar to /proc/sysrq-trigger<br>
3. enablement through gluster-cli command<br>
<br>
These options should be explained in the feature page, with the plan to<br>
provide the three options for 3.10. I'm happy to massage the patch from<br>
Poornima [0] and split it in 1 and 3. Additional improvements for 3<br>
might be needed, and we'll have to see who does that work. Point 2 is<br>
something I'll take on as well.<br>
<br>
What do others think about this?<br>
<br></blockquote><div><br></div><div>Sounds good to me. What are the additional improvements that you envision for 3? </div><div><br></div><div>Thanks,</div><div>Vijay</div></div></div></div>