On Apr 5, 2007, at 4:48 PM, Alan Robertson wrote:
Alan Robertson wrote:
Lars Marowsky-Bree wrote:
On 2007-04-04T11:41:44, Doug Knight [EMAIL PROTECTED] wrote:
The key word in my question was thinks. It would be useful to
the RA
if it could know what state the CRM thought it was in, so in
Andrew Beekhof wrote:
On Apr 5, 2007, at 4:48 PM, Alan Robertson wrote:
Alan Robertson wrote:
Lars Marowsky-Bree wrote:
On 2007-04-04T11:41:44, Doug Knight [EMAIL PROTECTED] wrote:
The key word in my question was thinks. It would be useful to the RA
if it could know what state the CRM
Lars Marowsky-Bree wrote:
On 2007-04-05T07:40:34, Alan Robertson [EMAIL PROTECTED] wrote:
That is why I'd suggest to only call it in start or post-notify; calling
it in post-notify basically implies it'll be called after every state
change.
But, for DRBD for example, the ability to become
Simon Horman wrote:
[ Reposting as I sent it to linux-ha-devel instead of
linux-ha-devel the first time around ]
This seems to be a bit of an easy trap to fall into.
Are there any fixes floating around? I was thinking
that perhaps a cluster id of some sort would be a good
idea. But I'm
On 2007-04-10T07:09:44, Alan Robertson [EMAIL PROTECTED] wrote:
As even calling crm_master and having it do a compare and
update-if-modified, or filtering it in the CIB directly requires to at
least contact and query the CIB, I'd probably still track the state in
the RA somewhere. (As to
Lars Marowsky-Bree wrote:
On 2007-04-10T07:09:44, Alan Robertson [EMAIL PROTECTED] wrote:
As even calling crm_master and having it do a compare and
update-if-modified, or filtering it in the CIB directly requires to at
least contact and query the CIB, I'd probably still track the state in
