[Linux-ha-dev] Ordering of OCF Start, Stop and Monitor actions

[Andrew Beekhof]

On 3/28/07, Doug Knight <dknight at wsi.com> wrote:
>
>  Hi Lars,
>  I've gone through your comments below, and I think I understand this a bit
> better. Let me state what I think I need to do, and see if I've got it now
> (starting with Node A master and Node B slave):
>
>  Node A: PostgreSQL master gets demoted - completes (basically just stops
> PostgreSQL)
>  Node B: PostgreSQL slave gets promoted - starts it up as new master server
>  Node A: PostgreSQL demoted master gets a post notify call with promote
> notify operation
>
>  At this point I know heartbeat has brought the new master server up (node
> B), and I can safely rsync and restart the new slave server (node A). Nice
> and clean... Also, I need to remember that notify will get called for all
> combinations, and if I'm only handling the post-promote combination, all
> others I need to simply return OCF_SUCCESS, right?

sounds plausable

>  The remaining question I have is, does adding notify to the <actions>
> meta-data and configuring the notify operation via the Add Operation on the
> GUI "activate" heartbeat's usage of notify? Or are there any other
> parameters/flags I need to set to enable using notify? I seem to remember
> there was mention of some configuration items for using notify.


stealing from an eample lmb gave somewhere else recently:

       <master_slave id="ms-drbd0">
         <meta_attributes id="ma-drbd0">
           <attributes>
             <nvpair id="ma-drbd0-1" name="clone_max" value="2"/>
             <nvpair id="ma-drbd0-2" name="clone_node_max" value="1"/>
             <nvpair id="ma-drbd0-3" name="master_max" value="1"/>
             <nvpair id="ma-drbd0-4" name="master_node_max" value="1"/>
             <nvpair id="ma-drbd0-5" name="notify" value="yes"/>
             <nvpair id="ma-drbd0-6" name="globally_unique" value="false"/>
           </attributes>
         </meta_attributes>
         <primitive id="drbd0" class="ocf" provider="heartbeat" type="drbd">
           <instance_attributes id="ia-drbd0">
             <attributes>
               <nvpair id="ia-drbd0-1" name="drbd_resource" value="r0"/>
             </attributes>
           </instance_attributes>
         </primitive>
       </master_slave>

>
>  Thanks,
>  Doug
>
>
>  On Tue, 2007-03-27 at 23:14 +0200, Lars Marowsky-Bree wrote:
>  On 2007-03-22T13:24:02, Doug Knight <dknight at wsi.com> wrote:
>
> Hi,
>
> I've been out a bit myself but now want to answer this.
>
> > Hi Alan,
> > I took a look at the drbd OCF script's notify function, and the online
> > documentation. I believe there is one circumstance where I need to make
> > use of the pre/post notify.
>
> The reason why drbd calls update_prefs (ie, crm_master) in the
> post(-start) notification, and not within start itself, is that by that
> time, start will have been completed on all (one or both) nodes.
>
> That means that by that time, it's safe to figure out which side is
> preferable for becoming master.
>
>
> > The last step in my development/testing has
> > to do with several steps I take to prepare the server that was primary
> > and is now becoming standby. First, the primary gets demoted, right?
>
> Yes.
>
> > Then the secondary gets promoted. The problem I have is that part of the
> > process of preparing the new standby requires that the new active server
> > process is up and accessible. If the demote has to complete before the
> > promote can begin, I cannot do the rsync in the demote, because the
> > promote hasn't started and placed the new primary in an accessible
> > state.
>
> That seems to be true for your scenario, yes.
>
> > So, if I understand the notify function, then I need a "post" process
> > section that looks for the master going "active" and accessible, so I
> > can do the rsync and start up the new standby, right?
>
> That you could do. The instances will get a post-promote notification,
> which could do what you want.
>
> > Can you expand a little on the notify processing? The web page just
> > lists the variables involved, and the drbd OCF script only makes use
> > of a few of them, and I need a more detailed explanation of how and
> > when they are used.
>
> Well, you get a pre-notification before start/stop/promote/demote happen
> anywhere and a post-notification after they have completed everywhere.
> That's basically the gist of it.
>
> Does that make it clearer, or do you have a specific question?
>
>
> Sincerely,
>  Lars
>
>
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>
>