[ClusterLabs] Antw: Re: Antw: [EXT] Re: Q: How to clean up a failed fencing operation?

[Klaus Wenninger]

On Fri, May 13, 2022 at 12:12 PM Ulrich Windl
<Ulrich.Windl at rz.uni-regensburg.de> wrote:
>
> >>> Klaus Wenninger <kwenning at redhat.com> schrieb am 13.05.2022 um 08:22 in
> Nachricht
> <CALrDAo1Dh_yAafCc5D6Ppz7YtjW7OsBoz+dWy+466ALNQDUnMQ at mail.gmail.com>:
> > On Tue, May 3, 2022 at 11:53 AM Ulrich Windl
> > <Ulrich.Windl at rz.uni-regensburg.de> wrote:
> >>
> >> >>> Reid Wahl <nwahl at redhat.com> schrieb am 03.05.2022 um 10:16 in
> Nachricht
> >> <CAPiuu98BFCiG8gkUOGLXYEyFjdOTahFeTXjWP79dBxDO71RTtA at mail.gmail.com>:
> >> > On Tue, May 3, 2022 at 12:36 AM Ulrich Windl
> >> > <Ulrich.Windl at rz.uni‑regensburg.de> wrote:
> >> >>
> >> >> Hi!
> >> >>
> >> >> I'm familiar with cleaning up various failed resource actions via
> >> > "crm_resource ‑C ‑r resource_name ‑N node_name ‑n operation".
> >> >> However I wonder wha tthe correct paraneters for a failed fencing
> operation
> >>
> >> > (that lingers around) are.
> >> >
> >> > stonith_admin ‑‑history '*' ‑‑cleanup
> >>
> >> Ah, a completely different command! Interestingly this does not produce
> any
> >> logs in syslog (no DC action).
> >
> > Fencing history is totally independent from failure history for
> > resources that is
> > recorded in the cib. That is part of the strategy to have the fencing
> > framework
> > operate kind of independently from DC, scheduler and stuff.
> > It lives purely within the framework built by the fenced instances and
> > broadcasted
> > between those instances to keep it current - or purged if requested.
> > DC role thus isn't relevant for working with the fencing history.
> > Of course operations on the fencing history can create logs but they may be
> > below the usually enabled level. Nothing there should influence the
> behavior
> > of the cluster (you can't purge pending actions).
>
> It's probably not formally defined, but I always felt that any state changes
> should be logged with severity "info" at least; actually I prefer "notice"
> (using "info" for "interesting" events).

Fencing history is just a memory-based distributed log.

>
> Regards,
> Ulrich
>
>
> >
> > Klaus
> >>
> >> Regards,
> >> Ulrich
> >>
> >>
> >> >
> >> >>
> >> >> crm_mon found:
> >> >> Failed Fencing Actions:
> >> >>   * reboot of h18 failed: delegate=h16,
> >> client=stonith_admin.controld.22336,
> >> > origin=h18, last‑failed='2022‑04‑27 02:22:52 +02:00' (a later attempt
> >> succeeded)
> >> >>
> >> >> Regards,
> >> >> Ulrich
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Manage your subscription:
> >> >> https://lists.clusterlabs.org/mailman/listinfo/users
> >> >>
> >> >> ClusterLabs home: https://www.clusterlabs.org/
> >> >>
> >> >
> >> >
> >> > ‑‑
> >> > Regards,
> >> >
> >> > Reid Wahl (He/Him), RHCA
> >> > Senior Software Maintenance Engineer, Red Hat
> >> > CEE ‑ Platform Support Delivery ‑ ClusterHA
> >> >
> >> > _______________________________________________
> >> > Manage your subscription:
> >> > https://lists.clusterlabs.org/mailman/listinfo/users
> >> >
> >> > ClusterLabs home: https://www.clusterlabs.org/
> >>
> >>
> >>
> >> _______________________________________________
> >> Manage your subscription:
> >> https://lists.clusterlabs.org/mailman/listinfo/users
> >>
> >> ClusterLabs home: https://www.clusterlabs.org/
> >
> > _______________________________________________
> > Manage your subscription:
> > https://lists.clusterlabs.org/mailman/listinfo/users
> >
> > ClusterLabs home: https://www.clusterlabs.org/
>
>
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/