On this mailing list, i critized several time heartbeat without much
result, so i send this text. It is a summary for archive purpose.
It has already been discussed in the past, so i dont see the need
to do it again.
In this text, i explain why i don't like heartbeat. Nevertheless i
appears to be the only one to claim this opinion, so a consensus
has been reached around heartbeat to think it is a 'good thing'.
I respect this consensus, even if i disagree.
Further, even if i dont like his program, alan roberston still
calmly explains its points of view and i appreciate that.
In short, what i don't like in heartbeat:
1. Heartbeat try to design/rewrite a network stack. i claim that IP already
does the job. IP has been designed/implemented by experienced people,
i think it would be a mistake not to use it.
Moreover to rewrite it will be a HUGE job, and very long to debug.
2. In rfc1925 we can find
" (5) It is always possible to aglutenate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea."
I strongly believe in that, the occam razor concept is close too.
i see heartbeat as the exact opposite. heartbeat tries to include
everything in it without reason.
I remember a sentence whom i unfortunatly forgot the author 'there 2
ways to design a protocol: to make it so simple that there obviously
no error, to make it so complex that there is no obvious error' i
think heartbeat fall in the second category and i would like it
to fall in the first.
In my opinion, a program called heartbeat should monitor the neighbors
life and report the result, no more. Others will take decisions based
on the data reported.
IF rewriting a network stack is needed(and not use IP), IF rewriting
a serial protocol (and not use slip/ppp) is needed, IF a reliable
multicast protocol is needed (what i question especially for a life
monitor), IF rewriting one is needed (and not used one of the ten
existing ones http://www.tascnets.com/mist/doc/mcpCompare.html),
heartbeat isnt the good place to implement it.
3. It isnt documented, so except the people who has the time to study
the code (i tried), nobody will review the custom security (btw it
is commonly admited that a unreviewed security should be assumed
untrustable), the custom network protocols etc... If there is
a mistake in it, the more we wait the harder it will be to fix.
This is undesirable in general but really harmfull in a HA environment.
What i like in heartbeat:
1. it exists and so complies to the linus's rule 'show me the sources'
I hope i made my opinions clear. I will stop to repeat my critics
about heartbeat until i have a source to replace it. I am have
no time to write one now, so enjoy heartbeat :)
result, so i send this text. It is a summary for archive purpose.
It has already been discussed in the past, so i dont see the need
to do it again.
In this text, i explain why i don't like heartbeat. Nevertheless i
appears to be the only one to claim this opinion, so a consensus
has been reached around heartbeat to think it is a 'good thing'.
I respect this consensus, even if i disagree.
Further, even if i dont like his program, alan roberston still
calmly explains its points of view and i appreciate that.
In short, what i don't like in heartbeat:
1. Heartbeat try to design/rewrite a network stack. i claim that IP already
does the job. IP has been designed/implemented by experienced people,
i think it would be a mistake not to use it.
Moreover to rewrite it will be a HUGE job, and very long to debug.
2. In rfc1925 we can find
" (5) It is always possible to aglutenate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea."
I strongly believe in that, the occam razor concept is close too.
i see heartbeat as the exact opposite. heartbeat tries to include
everything in it without reason.
I remember a sentence whom i unfortunatly forgot the author 'there 2
ways to design a protocol: to make it so simple that there obviously
no error, to make it so complex that there is no obvious error' i
think heartbeat fall in the second category and i would like it
to fall in the first.
In my opinion, a program called heartbeat should monitor the neighbors
life and report the result, no more. Others will take decisions based
on the data reported.
IF rewriting a network stack is needed(and not use IP), IF rewriting
a serial protocol (and not use slip/ppp) is needed, IF a reliable
multicast protocol is needed (what i question especially for a life
monitor), IF rewriting one is needed (and not used one of the ten
existing ones http://www.tascnets.com/mist/doc/mcpCompare.html),
heartbeat isnt the good place to implement it.
3. It isnt documented, so except the people who has the time to study
the code (i tried), nobody will review the custom security (btw it
is commonly admited that a unreviewed security should be assumed
untrustable), the custom network protocols etc... If there is
a mistake in it, the more we wait the harder it will be to fix.
This is undesirable in general but really harmfull in a HA environment.
What i like in heartbeat:
1. it exists and so complies to the linus's rule 'show me the sources'
I hope i made my opinions clear. I will stop to repeat my critics
about heartbeat until i have a source to replace it. I am have
no time to write one now, so enjoy heartbeat :)