On Wed, Nov 21, 2012 at 07:06:35PM +0100, Lars Marowsky-Bree wrote: > On 2012-11-21T18:02:49, Dejan Muhamedagic <de...@suse.de> wrote: > > > > What would you think of OCF_RESKEY_RA_TRACE ? > > A meta attribute perhaps? That wouldn't cause a resource > > restart. > > Point, but - meta attributes so far were mostly for the PE/pacemaker, > this would be for the RA.
Not exactly for the RA itself. The RA execution would just be observed. The attribute is consumed by others. Whether it is PE or lrmd or something else makes less of a difference. It is up to these subsystems to sort the meta attributes out. > Would a changed definition for a resource we're trying to trace be an > actual problem? I mean, tracing clearly means you want to trace an > resource action, so one would put the attribute on the resource before > triggering that. > > (It can also be put on in maintenance mode, avoiding the restart.) > > > > Our include script could > > > enable that; it's unlikely that the problem occurs prior to that. > > > > > > - never (default): Does nothing > > > - always: Always trace, write to $(which path?)/raname.rscid.$timestamp > > > > bash has a way to send trace to a separate FD, but that feature > > is available with version >=4.x. Otherwise, it could be messy to > > separate the trace from the other stderr output. Of course, one > > could just redirect stderr in this case. I suppose that that > > would work too. > > I assume that'd be easiest. > > (And people not using bash can write their own implementation for this. > ;-) > > > > - on-error: always trace, but delete on successful exit > > Good idea. > > > > > hb_report/history explorer could gather this too. > > Right. > > > > > (And yes I know this introduces a fake parameter that doesn't really > > > exist. But it'd be so helpful.) > > > > > > Sorry. Maybe I'm getting carried away ;-) > > > > Good points. I didn't really think much (yet) about how to > > further facilitate the feature, just had a vague idea that > > somehow lrmd should set the environment variable. > > Sure. LRM is an other obvious entry point for increased > tracing/logging. That could also work. > > > Perhaps we could do something like this: > > > > # crm resource trace <rsc_id> [<action>] [<when-to-trace>] > > > > This would set the appropriate meta attribute for the resource which > > would trickle down to the RA. ocf-shellfuncs would then do whatever's > > necessary to setup the trace. The file management could get tricky > > though, as we don't have a single point of exit (and trap is already > > used elsewhere). > > The file/log management would be easier to do in the LRM - and also > handle the timeout situation; that could also make use of the "redirect > trace elsewhere" if the shell is new enough. Indeed. Until then, ocf-shellfuncs can fallback to some well known location. Thanks, Dejan > > Regards, > Lars > > -- > Architect Storage/HA > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, > HRB 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > _______________________________________________________ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
