[ClusterLabs] Antw: Re: fencing on iscsi device not working

[Ken Gaillot]

On Wed, 2019-11-06 at 08:04 +0100, Ulrich Windl wrote:
> > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 05.11.2019 um
> > > > 16:05 in
> 
> Nachricht
> <d2e2114a48ef66535e11fe2fe5970d2bd687c83d.camel at redhat.com>:
> > Coincidentally, the documentation for the pcmk_host_check default
> > was
> > recently updated for the upcoming 2.0.3 release. Once the release
> > is
> > out, the online documentation will be regenerated, but here is the
> > text:
> > 
> > Default
> > ‑‑‑‑‑‑‑
> > static‑list if either pcmk_host_list or pcmk_host_map is set,
> > otherwise
> > dynamic‑list if the fence device supports the list action,
> > otherwise
> > status if the fence device supports the status action, otherwise
> > none
> 
> I'd make that an itemized list with four items. I thinks it would be
> easer to
> understand.

Good idea; I edited it so that the default and description are
combined:

How to determine which machines are controlled by the device. Allowed
values:

* +static-list:+ check the +pcmk_host_list+ or +pcmk_host_map+
attribute (this is the default if either one of those is set)

* +dynamic-list:+ query the device via the "list" command (this is
otherwise the default if the fence device supports the list action)

* +status:+ query the device via the "status" command (this is
otherwise the default if the fence device supports the status action)

* +none:+ assume every device can fence every machine (this is
otherwise the default)


> > 
> > On Tue, 2019‑11‑05 at 11:01 +0100, wferi at niif.hu wrote:
> > > Roger Zhou <ZZhou at suse.com> writes:
> > > 
> > > > On 11/3/19 12:56 AM, wferi at niif.hu wrote:
> > > > 
> > > > > Andrei Borzenkov <arvidjaar at gmail.com> writes:
> > > > > 
> > > > > > According to documentation, pcmk_host_list is used only if
> > > > > > pcmk_host_check=static‑list which is not default, by
> > > > > > default
> > > > > > pacemaker
> > > > > > queries agent for nodes it can fence and fence_scsi does
> > > > > > not
> > > > > > return
> > > > > > anything.
> > > > > 
> > > > > The documentation is somewhat vague here.  The note about
> > > > > pcmk_host_list
> > > > > says: "optional unless pcmk_host_check is static‑list".  It
> > > > > does
> > > > > not
> > > > > state how pcmk_host_list is used if pcmk_host_check is the
> > > > > default
> > > > > dynamic‑list, 
> > > > 
> > > > The confusion might be because of "the language barrier".
> > > > 
> > > > My interpretation is like this:
> > > > 
> > > > 1. pcmk_host_list is used only if pcmk_host_check is
> > > > static‑list.
> > > > 
> > > > 2. pcmk_host_check's default is dynamic‑list.
> > > >     That means, by default pcmk_host_list is not used at all.
> > > 
> > > But this interpretation does not align with reality:
> > > 
> > > > > but I successfully use such setups with Pacemaker 1.1.16
> > > > > with fence_ipmilan.
> > > 
> > > (I mean I don't set pcmk_host_check on my fence_ipmilan
> > > resources,
> > > only
> > > pcmk_host_list, and they work.)
> > > 
> > > Unless:
> > > 
> > > > > the behavior is different in 2.0.1 (the version in Debian
> > > > > buster).
> > > 
> > > That's why I asked:
> > > 
> > > > > Ram, what happens if you set pcmk_host_check to static‑list?
> > > 
> > > Of course the developers are most welcome to chime in with their
> > > intentions and changes concerning this, I haven't got the time to
> > > dig
> > > into the core right now.  Tough I'm very much interested for my
> > > own
> > > sake
> > > as well, because I'm about to bring up a buster cluster with very
> > > similar config.
> > 
> > ‑‑ 
> > Ken Gaillot <kgaillot at redhat.com>
> > 
> > _______________________________________________
> > 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/
-- 
Ken Gaillot <kgaillot at redhat.com>