Thanks Ken.
I will give it a shot.
http://oss.clusterlabs.org/pipermail/pacemaker/2011-August/011271.html
On this thread, if I interpret it correctly, his problem was solved when he
swapped the anti-location constraint
>From (mapping to my example)
cu_2 with cu_4 (score:-INFINITY)
cu_3 with cu_4
On 10/17/2016 12:42 PM, Israel Brewster wrote:
> I have one resource agent (redis, to be exact) that sometimes apparently
> fails to start on the first attempt. In every case, simply running a
> 'pcs resource cleanup' such that pacemaker tries to start it again
> successfully starts the process.
On 10/17/2016 09:55 AM, Nikhil Utane wrote:
> I see these prints.
>
> pengine: info: rsc_merge_weights:cu_4: Rolling back scores from cu_3
> pengine:debug: native_assign_node:Assigning Redun_CU4_Wb30 to cu_4
> pengine: info: rsc_merge_weights:cu_3: Rolling back scores from cu_2
I have one resource agent (redis, to be exact) that sometimes apparently fails to start on the first attempt. In every case, simply running a 'pcs resource cleanup' such that pacemaker tries to start it again successfully starts the process. Now, obviously, the proper thing to do is to figure out
I see these prints.
pengine: info: rsc_merge_weights: cu_4: Rolling back scores from cu_3
pengine:debug: native_assign_node: Assigning Redun_CU4_Wb30 to cu_4
pengine: info: rsc_merge_weights: cu_3: Rolling back scores from cu_2
pengine:debug: native_assign_node: Assigning
On 2016-10-17 02:12, Ulrich Windl wrote:
Have you tried a proper variant of "lsof" before? So maybe you know
which process might block the device. I also think if you have LVM on
top of DRBD, you must deactivate the VG before trying to unmount.
No LVM here: AFAIMC these days it's another
