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