Great, I'll give it a try thanks for the input
On Thu, Sep 30, 2010 at 1:09 PM, Cnut Jansen <w...@cnutjansen.eu> wrote: > Am 30.09.2010 09:49, schrieb Jonathan Petersson: >> deb-fw1:~# ocf-tester -L -n conntrackd >> /usr/lib/ocf/resource.d/heartbeat/conntrackd >> Using lrmd/lrmadmin for all tests >> Beginning tests for /usr/lib/ocf/resource.d/heartbeat/conntrackd... >> * rc=0: Monitoring a stopped resource should return 7 >> * Your agent does not support the notify action (optional) >> * Your agent does not support the demote action (optional) >> * Your agent does not support the promote action (optional) >> * Your agent does not support master/slave (optional) >> * rc=0: Monitoring a stopped resource should return 7 >> * rc=0: Monitoring a stopped resource should return 7 >> * rc=0: Monitoring a stopped resource should return 7 >> Tests failed: /usr/lib/ocf/resource.d/heartbeat/conntrackd failed 4 tests >> >> Not 100% sure codewise what I should change. >> >> Maybe it would make sense to add master/slave to handle the >> state-transition and have start/stop handle whether the daemon is >> alive or not. However I'm not entirely sure how the crm configuration >> statement for this should look given that the daemon should be started >> on both nodes running in either master or slave mode, do you have an >> example for this? > > Hi, > > without having had a look onto your RA and its necessary parameters etc. > at all yet: > I had similiar issues with my Tomcat6- and Apache-RAs, though they > worked without problems in the cluster. When I had the time and ambition > to finally also make them ocf-tester-compliant (meanwhile they are > anyway, without special additional handlers for the ocf-tester), I could > track problems down to various timing issues. Not only that back at that > time I still used start-delay for the monitor-op in the cluster (because > back then I didn't check and wait for i.e. Tomcat being operational in > start-action respectively not anymore and all files being closed in > stop-action yet), but also exspecially that ocf-tester didn't set i.e. a > $OCF_RESKEY_CRM_meta_timeout, on which my RA back then still depended on > for its monitor-action (now it's not anymore, but back then I was still > eager about allways cleanly exiting with at least an OCF_ERR_* too, > instead of just simply letting it time out and having Pacemaker handle > that situation (-; ). > Also - since I don't know about your RA's parameters, but at least for > mine it helped, due to some not-up-to-date-anymore-defaults - it might > be necessary to tell ocf-tester to pass over some OCF-parameters, to > have them available as $OCF_RESKEY_*. You do that with the "-o"-option > to ocf-tester, like > -o log_level="debug" > to have ocf-tester set an env.-var. $OCF_RESKEY_log_level with the value > "debug". > > This was my complete command for calling ocf-tester back then, long time > ago (i.e. still includes my switch for special ocf-tester-handler, > etc.): (-; > ocf-tester -n testTom -o log_debug="/tmp/debug-tomcat.log" -o > monitor_timeoutPerTry="5" -o monitor_precheckDB="1" -o log_level="debug" > -o stopith_enabled="1" -o > monitor_url="http://localhost:8080/opencms/opencms/test/cluster.html"; -o > agent_timebuffer="4000" -o ocftester="y" /usr/lib/ocf/resource.d/cj/tomcat > > Hope that helps you a little on making ocf-tester accept your RA too. (-; > > Cnut Jansen > > _______________________________________________________ > 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/ > _______________________________________________________ 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/
