Hi,
On Sat, Mar 02, 2013 at 08:19:23AM -0500, David Coulson wrote:
> Running Pacemaker 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
>
> I noticed we have inconsistent ordering of meta/params in our
> configuration - For some resources, meta comes before params, in
> some cases after. In t
On 3/3/13 1:00 PM, Lars Marowsky-Bree wrote:
My memory may be very faulty, but I thought this didn't lead to the
failure actually be cleaned up automatically, but "merely" ignored
post-timeout.
Perhaps 'clean up' is the wrong phrase. But I've absolutely seen it
remove the failure out of 'crm_mo
On 2013-03-03T12:29:55, David Coulson wrote:
> We've seen instances where failure-timeout is set, but Pacemaker never seems
> to clean up the failure. First thought was it didn't actually utilize the
> meta failure-timeout parameter if it was in the wrong place. Probably need
> to troubleshoot it
On 3/2/13 8:22 AM, Lars Marowsky-Bree wrote:
Unless it annoys you, this is actually harmless.
Otherwise, params first is what I tend to use.
Regards,
Lars
We've seen instances where failure-timeout is set, but Pacemaker never
seems to clean up the failure. First thought was it didn't a
On 2013-03-02T08:19:23, David Coulson wrote:
> I noticed we have inconsistent ordering of meta/params in our configuration
> - For some resources, meta comes before params, in some cases after. In the
> case below, both. I am assuming meta before params is the correct way to do
> it, but wanted t
Running Pacemaker 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
I noticed we have inconsistent ordering of meta/params in our
configuration - For some resources, meta comes before params, in some
cases after. In the case below, both. I am assuming meta before params
is the correct way t
