On 2007-05-16T13:22:02, Simon Horman [EMAIL PROTECTED] wrote:
Indeed, that's normal. v1 configurations will start the resources on
take-over, and doesn't have enough memory to know it already has them.
As start must succeed if already started, no harm should come from
this for correct resource
On 2007-04-08T02:01:45, Simon Horman [EMAIL PROTECTED] 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
On 2006-06-08T08:21:38, Alan Robertson [EMAIL PROTECTED] wrote:
Please fix it everywhere, if you don't mind.
Thanks Horms!!
Of course, special attention needs to be paid to upgrading to (and
possibly, back off from) a version with that change.
I'm pretty sure that RPM handles that
On 2006-06-08T07:15:01, Alan Robertson [EMAIL PROTECTED] wrote:
Unfortunately heartbeat (for fairly broken reasons IMHO) really
needs those files there.
Could we symlink 'em somewhere?
Yes, I think that is a good solution (short of rearanging the
resource paths completely). I can do this
On 2006-06-08T08:47:41, Alan Robertson [EMAIL PROTECTED] wrote:
There may be files in there which aren't owned by our package though, or
modified.
Huh?
I just meant make individual symlinks for a individual binaries. NOT a
symlink for the entire directory.
Ahhh. Ok. I thought you wanted
On 2005-07-19T00:04:41, Horms [EMAIL PROTECTED] wrote:
For reference, here is a version of the patch that applies
(and hopefully works) with the CVS HEAD branch.
Looks OK.
Alan, could we get the code review process to be a at-least-two-pairs of
eyes system? It's difficult to handle changes
6 matches
Mail list logo
