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

[Doug Knight]

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?

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.

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.community.tummy.com/pipermail/linux-ha-dev/attachments/20070328/cb019fca/attachment.html