> >>> Hi, All > >>> > >>> I add the new function for heartbeat-2.0.8 and attached its patch file. > >>> > >>> The function is to apply the new timeout parameters ( keepalive, > >>> deadtime, deadping, warntime ) without stopping the heartbeat services. > >>> Currently heartbeat boot scripts supply the 'reload' or 'forcereload' > >>> function, but it, they are same, does stop the services and the HA > >>> services are moved to standby node, because its process kills the forked > >>> heartbeat processes and clients ( crmd etc. ). > >>> So, we think to without suspending the services make the changing > >>> parameters to apply to driving nodes. Current feature is following. > >>> 1. changing ha.cf <http://ha.cf> file for 4 parameters > >>> 2. send working parent heartbeat process signal SIGRTMAX ( e.g. kill -s > >>> SIGRTMAX `cat /var/run/heartbeat.pid` (Why do I choose SIGRTMAX? I do > >>> not find the unused good signal.) > >>> > >>> As we research the heatbeat, it may be safety. And I want to listen to > >>> your issues for patch and functions. > >> Sorry to be coming in so late on this, but I was working on the release > >> for many weeks now. I really like the idea of dynamically modifying the > >> heartbeat configuration - but if you're going to go to the trouble to do > >> it, I'd like to see it done more generally. > >> > >> In other words, I'd like to be able to change nearly any parameter in > >> ha.cf at run time without restarting heartbeat. > >> > >> This would require reworking (and improving) the way heartbeat starts > >> up. This would be probably about twice or three times as much work as > >> what you've done, but it would be much more useful, and much more general. > >> > >> In the end, if done right, it could be groundwork to letting let us > >> eventually be able receive config updates from the CIB. [I know there's > >> a bootstrapping issue, but we can deal with that when we get to deciding > >> to do that work]. > >> > >> I have thought about this and have some specific ideas on what kinds of > >> things need to be done to make this happen. > > > > Hi, Alan. > > > > I understood what you say and think it is very good idea to tread all > > parameters in ha.cf. I thought my implementation is for testing and it > > is better that you, ha-dev team, make its feature. > > I don't know quite what you meant by "it is better that you, ha-dev > team, make it's feature".
I am sorry for poor English. It means that the feature you think to make is better than what I made. If possible, could you show the schedule Best Regards MATSUDA, Daiki _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
