Re: [ClusterLabs] Antw: Re: fencing on iscsi device not working
On Thu, 2019-11-07 at 07:43 +, Roger Zhou wrote: > > On 11/7/19 1:55 AM, Andrei Borzenkov wrote: > > 06.11.2019 18:55, Ken Gaillot пишет: > > > On Wed, 2019-11-06 at 08:04 +0100, Ulrich Windl wrote: > > > > > > > Ken Gaillot schrieb am 05.11.2019 > > > > > > > um > > > > > > > 16:05 in > > > > > > > > Nachricht > > > > : > > > > > 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) > > > > > > > Oops, now it became even more ambiguous. What if both > > pcmk_host_list is > > set *and* device supports "list" (or "status") command? Previous > > variant > > at least was explicit about precedence. > > > > "Otherwise" above is hard to attribute correctly. I really like > > previous > > version more. > > +1 > > plus 2 cents: > > I feel confused between Default and Assigned value if combine them > in > the description as above. I prefer to keep them separate. > > I guest Ken might want to keep Pacemaker_Explained DOC more readable > at > the end of the day, ie. to avoid too many words in Default column > [1]. > For that, might be we can do differently, like the mockup [2]. > > [1] > https://github.com/ClusterLabs/pacemaker/blob/d863971b7e0c56fbe6cc12815348e8e39b2e25c4/doc/Pacemaker_Explained/en-US/Ch-Fencing.txt#L182 > > [2] > > > pcmk_host_check > > string > > +NOTE+ > > a|How to determine which machines are controlled by the device. > > * +NOTE:+ > The default value is 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. > > Allowed values: > > * +dynamic-list:+ query the device via the "list" command > * +static-list:+ check the +pcmk_host_list+ or +pcmk_host_map+ > attribute > * +status:+ query the device via the "status" command > * +none:+ assume every device can fence every machine Elaborating on that approach, how about: Default: "The value appropriate to other configuration options and device capabilities (see note below)" Description unchanged Note: "The default value for +pcmk_host_check+ is +static-list+ if either +pcmk_host_list+ or +pcmk_host_map+ is configured. If neither of those are configured, the default is +dynamic-list+ if the fence device supports the list action, or +status+ if the fence device supports the status action but not the list action. If none of those conditions apply, the default is +none+." > > Cheers, > Roger > > > > > > * +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) -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Antw: Re: fencing on iscsi device not working
On 11/7/19 1:55 AM, Andrei Borzenkov wrote: > 06.11.2019 18:55, Ken Gaillot пишет: >> On Wed, 2019-11-06 at 08:04 +0100, Ulrich Windl wrote: >> Ken Gaillot schrieb am 05.11.2019 um >> 16:05 in >>> >>> Nachricht >>> : 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) >> > > Oops, now it became even more ambiguous. What if both pcmk_host_list is > set *and* device supports "list" (or "status") command? Previous variant > at least was explicit about precedence. > > "Otherwise" above is hard to attribute correctly. I really like previous > version more. +1 plus 2 cents: I feel confused between Default and Assigned value if combine them in the description as above. I prefer to keep them separate. I guest Ken might want to keep Pacemaker_Explained DOC more readable at the end of the day, ie. to avoid too many words in Default column [1]. For that, might be we can do differently, like the mockup [2]. [1] https://github.com/ClusterLabs/pacemaker/blob/d863971b7e0c56fbe6cc12815348e8e39b2e25c4/doc/Pacemaker_Explained/en-US/Ch-Fencing.txt#L182 [2] |pcmk_host_check |string |+NOTE+ a|How to determine which machines are controlled by the device. * +NOTE:+ The default value is 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. Allowed values: * +dynamic-list:+ query the device via the "list" command * +static-list:+ check the +pcmk_host_list+ or +pcmk_host_map+ attribute * +status:+ query the device via the "status" command * +none:+ assume every device can fence every machine Cheers, Roger > >> * +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) >> > ___ > 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/
Re: [ClusterLabs] Antw: Re: fencing on iscsi device not working
06.11.2019 18:55, Ken Gaillot пишет: > On Wed, 2019-11-06 at 08:04 +0100, Ulrich Windl wrote: > Ken Gaillot schrieb am 05.11.2019 um > 16:05 in >> >> Nachricht >> : >>> 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) > Oops, now it became even more ambiguous. What if both pcmk_host_list is set *and* device supports "list" (or "status") command? Previous variant at least was explicit about precedence. "Otherwise" above is hard to attribute correctly. I really like previous version more. > * +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) > ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Antw: Re: fencing on iscsi device not working
On Wed, 2019-11-06 at 08:04 +0100, Ulrich Windl wrote: > > > > Ken Gaillot schrieb am 05.11.2019 um > > > > 16:05 in > > Nachricht > : > > 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, wf...@niif.hu wrote: > > > Roger Zhou writes: > > > > > > > On 11/3/19 12:56 AM, wf...@niif.hu wrote: > > > > > > > > > Andrei Borzenkov 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 > > > > ___ > > 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 ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Antw: Re: fencing on iscsi device not working
>>> Ken Gaillot schrieb am 05.11.2019 um 16:05 in Nachricht : > 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. > > On Tue, 2019‑11‑05 at 11:01 +0100, wf...@niif.hu wrote: >> Roger Zhou writes: >> >> > On 11/3/19 12:56 AM, wf...@niif.hu wrote: >> > >> > > Andrei Borzenkov 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 > > ___ > 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/
