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

[Doug Knight]

On Wed, 2007-03-28 at 09:14 +0200, Andrew Beekhof wrote:
> On 3/28/07, Alan Robertson <alanr at unix.sh> wrote:
> > Andrew Beekhof wrote:
> > >
> > > On Mar 22, 2007, at 2:13 AM, Alan Robertson wrote:
> > >
> > >> Doug Knight wrote:
> > >>> Hi Andrew,
> > >>> I had just started reviewing both of thes scripts, and reviewed the
> > >>> Multistate and clone resource pages on the web site. It looks like
> > >>> multistate is how I need to handle it, but a couple of questions first.
> > >>>
> > >>> 1. I noticed that the write-up says the resource must come up on each of
> > >>> the servers in "shadow" mode first, then one gets promoted. Does this
> > >>> imply a "start" on both servers, and the OCF start function determining
> > >>> which server is active vs shadow (I'm picturing a check in the OCF
> > >>> script to determine postgresql standby mode = shadow/crm_master value
> > >>> low, and postgresql active mode = active/crm_master value high), then a
> > >>> promote to the active server?
> > >>>
> > >>> 2. I noticed that the drbd OCF script contains a "notify" function,
> > >>> where the Stateful OCF script does not. The notify function looks to be
> > >>> where the important actions are taken (calling drbd_start_phase_2,
> > >>> pre/post, etc). Is the notify function necessary, or is it sufficient in
> > >>> my case to handle it through the start|stop|promote|demote functions?
> > >>>
> > >>> Thanks for your help,
> > >>> Doug
> > >>
> > >> Andrew's out for a while.
> > >>
> > >> The start function starts you up in slave/secondary mode.  All resources
> > >> initially start up in "slave" mode.
> > >>
> > >> A set of servers is chosen to run the resources on (it might be one,
> > >> two, the whole set, etc. depending on clone_max and clone_node_max and
> > >> the usual constraints).
> > >>
> > >> They are started on the selected nodes using "start"
> > >>
> > >> During the start operation, you are given the chance to declare yourself
> > >> ready to become master or not by using the crm_master command line tool.
> > >>
> > >> I believe that your resource can run that command any time they like -
> > >> for example at a monitor operation...  But, it is mandatory that they
> > >> run it when they first start up.
> > >
> > > mandatory in the sense that nothing will get promoted until someone,
> > > somewhere runs it.
> > > but the exact timing is completely up to the user/admin/RA... it is even
> > > possible to run it manually if you have to
> >
> > I originally assumed what you said, but the docs contradict that by
> > calling it mandatory (and not qualifying the term).  And the code seems
> > to indicate that you can ONLY run it from an RA.
> 
> if you know which OCF environment variables to set, then you can
> potentially run it from anywhere... but most people wont need to run
> it outside of the RA

What I did was to set up the defaults within the OCF script to point to
the locations and values I needed for this specific instance I'm
testing. That way I can manually execute the script pretty well. That's
when I ran into the crm_master spinning. I did need to manually set the
OCF_RESOURCE_INSTANCE so that during the start function I could attempt
to find if the resource already was running in the cluster somewhere.
Definitely made it possible to test all the associated functions like
stop, usage. methods, meta-data, monitor, etc.


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