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 ?

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/

Reply via email to