On Wed, 2007-03-28 at 09:14 +0200, Andrew Beekhof wrote: > On 3/28/07, Alan Robertson <[EMAIL PROTECTED]> 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: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ >
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
