Le 29/06/2013 01:22, Andrew Beekhof a écrit :
On 29/06/2013, at 12:22 AM, Digimer <li...@alteeve.ca> wrote:
On 06/28/2013 06:21 AM, Andrew Beekhof wrote:
On 28/06/2013, at 5:22 PM, Lars Marowsky-Bree <l...@suse.com> wrote:
On 2013-06-27T12:53:01, Digimer <li...@alteeve.ca> wrote:
primitive fence_n01_psu1_off stonith:fence_apc_snmp \
params ipaddr="an-p01" pcmk_reboot_action="off" port="1"
pcmk_host_list="an-c03n01.alteeve.ca"
primitive fence_n01_psu1_on stonith:fence_apc_snmp \
params ipaddr="an-p01" pcmk_reboot_action="on" port="1"
pcmk_host_list="an-c03n01.alteeve.ca"
So every device twice, including location constraints? I see potential
for optimization by improving how the fence code handles this ... That's
abhorrently complex. (And I'm not sure the 'action' parameter ought to
be overwritten.)
I'm not crazy about it either because it means the device is tied to a specific
command.
But it seems to be something all the RHCS people try to do...
Maybe something in the rhcs water cooler made us all mad... ;)
Glad you got it working, though.
location loc_fence_n01_ipmi fence_n01_ipmi -inf: an-c03n01.alteeve.ca
[...]
I'm not sure you need any of these location constraints, by the way. Did
you test if it works without them?
Again, this is after just one test. I will want to test it several more
times before I consider it reliable. Ideally, I would love to hear
Andrew or others confirm this looks sane/correct.
It looks correct, but not quite sane. ;-) That seems not to be
something you can address, though. I'm thinking that fencing topology
should be smart enough to, if multiple fencing devices are specified, to
know how to expand them to "first all off (if off fails anywhere, it's a
failure), then all on (if on fails, it is not a failure)". That'd
greatly simplify the syntax.
The RH agents have apparently already been updated to support multiple ports.
I'm really not keen on having the stonith-ng doing this.
This doesn't help people who have dual power rails/PDUs for power
redundancy.
I'm yet to be convinced that having two PDUs is helping those people in the
first place.
If it were actually useful, I suspect more than two/three people would have
asked for it in the last decade.
Well, it's probably because many people are still toying around with
pacemaker and I assume that not many advanced RHCS users have yet tried
to translate their current RHCS cluster to pacemaker. Digimer and I did,
and we both failed having the equivalent <device> configuration we had
in our RHCS setup.
I suspect more and more people will hit this issue soon or later.
Anyway, whatever will follow in terms of configuration primitive or API,
thanks to Digimer tests we now have something (even if unelegant) working :)
--
Cheers,
Florian Crouzat
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
