Description of problem: Problem with fence_wti Version-Release number of selected component (if applicable): fence-1.32.1-0 How reproducible: After removing the network from one of the nodes, the other node is trying to fence the failed node. This succeeds, after that the status of the fence is checked and the following appears in messages file: Sep 29 14:59:45 dbn42 fenced[5280]: fencing node "dbn41.mz.local" Sep 29 14:59:48 dbn42 fenced[5280]: agent "fence_wti" reports: failed: plug not off () Sep 29 14:59:48 dbn42 fenced[5280]: fence "dbn41.mz.local" failed We already applied the change mentioned in bugzilla#162805. It looks like there goes something wrong in the loop that checks the status of the ports (seems to be running this loop only one time!). Only one line is of the status output is analysed. We are using a WTI NPS-230. Steps to Reproduce: 1. 2. 3. Actual results: Status check of the port fails and keeps running in a loop. The failed cluster resources are not brought online on the other node. Expected results: Additional info:
looking for hardware to test on.
Ryan - can you try and reproduce this, please? I have never been able to, with the wti switch here in Westford...I don't know if you guys have this exact model of WTI product in msp...
I'm attempting to reproduce this with a WTI NPS-115 that I have setup in the lab here. It appears to be identical to the NPS-230 except that it is 115 VAC, wheras the NPS-230 is 230 VAC.
I have not been able to reproduce this on an NPS-115, which should be identical to the NPS-230 except for VAC (mentioned above). Two things to mention: 1. The WTI NPS devices have a configurable "boot delay" which is used to set the time between the off/on of a reboot operation. It seems possible that boot delay could be set small enough that by the time we check the status (expecting "off") we see that it is "on". However, I tried this with the lowest possible setting (1 sec) and it did not occur. Even if this were the case, I would have expected the log messages to suggest that is fould the state to be "ON". In the log messages above, it appears the state is unknown. 2. There may be a very slight change in the console format due to different firmware revisions. It appears that the switch I was testing with has version 2.00. I am closing this since I am unable to reproduce this bug. If this continues to be a problem, please reopen this bug with addition information, including the firmware version, etc.