On Thu, Jan 05, 2017 at 11:26:19PM -0500, Vijay Bellur wrote: > On Thu, Jan 5, 2017 at 8:40 AM, Niels de Vos <ndevos@xxxxxxxxxx> 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@xxxxxxxxxx> 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? I dont remember anymore and will look into this further next week. Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
