Hi Holger, On Sat, Feb 19, 2011 at 05:59:36PM +0100, Holger Teutsch wrote: > On Thu, 2011-02-10 at 16:39 +0100, Holger Teutsch wrote: > > On Thu, 2011-02-10 at 13:07 +0100, Dejan Muhamedagic wrote: > > > On Wed, Feb 09, 2011 at 07:38:49PM +0100, Holger Teutsch wrote: > > > > Hi, > > > > please find enclosed the revised version. > > > > > > > > -holger > > > > > > > > On Wed, 2011-02-09 at 14:03 +0100, Dejan Muhamedagic wrote: > > > > > Hi, > > > > > > > > > > > > > > Please find below some comments. > > > [...] > > > > > > # > > > > > > # maintain the fal (first active log) attribute > > > > > > # db2_fal_attrib DB {set val|get|delete} > > > > > > # > > > > > > db2_fal_attrib() { > > > > > > local db=$1 > > > > > > local attr > > > > > > > > > > > > attr=db2hadr_${instance}_${db}_fal > > > > > > > > > > > > case "$2" in > > > > > > set) > > > > > > crm_attribute -t crm_config -n $attr -v "$3" > > > > > > > > > > Hmm, this is an attribute which should be on the master > > > > > right? Using crm_config for that looks wrong. I think > > > > > that it should go into the node status. > > > > > > > > No, it is an attribute that communicates the log position from the > > > > Master node to a restarting slave node. > > > > > > crm_config is for static configuration and actually for cluster > > > wide properties which are to be interpreted by the CRM. Now, I > > > cannot say how does db2 promote/demote work, but isn't it > > > possible to keep that as a dynamic node attribute? I think that > > > you should get information through the environment about which > > > node is currently the master. Then, the slave can read whichever > > > attribute it needs from that node's attributes. Can somebody with > > > more experience in ms resources confirm? > > > > > > > I see your point. I looked at the env during a start operation. > > Unfortunately no indication about the current master. I assume it can be > > done with notifications but these are asynchronous to the start > > operation. That means stuffing the info into a file, maintaining this, > > race conditions etc. That would be a major reengineering + difficult > > Q/A. > > > > Dejan, > meanwhile I was able to avoid this. It is now a node attribute with life > time reboot. > > How to proceed in this matter ? > Do you prefer to get a patch series based on the the last submitted > version our should I resubmit a complete file ?
This is a new code, so either way is OK. That is, whichever way you find it easier to follow. Cheers, Dejan > Regards > Holger > > _______________________________________________________ > 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/ _______________________________________________________ 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/