Hi Hideo-san, On Wed, Jan 25, 2012 at 10:09:26AM +0900, [email protected] wrote: > Hi Dejan, > > Thank you for comments. > > > > > > > Now the ocft test fails: > > > > > > > > > > > > 2012/01/23_21:39:40 ERROR: IP address [127.0.0.3] is a loopback > > > > > > address, thus can not be preferred source address > > > > > > > > > > > > Any idea how to update the ocft test case? > > > > > > > > > > I try this problem, too. > > > > > > > > I carried out ocf-tester with three cases. > > > > > > > > Case1) I carry it out after improving an address by ifconfig command. > > > > > > > > [root@rh57-3 ClusterLabs-resource-agents-7edbe1d]# ifconfig eth0:1 > > > > 192.168.40.7 up > > > > [root@rh57-3 ClusterLabs-resource-agents-7edbe1d]# ocf-tester -v -n > > > > IPsrcaddr -o ipaddress=192.168.40.7 > > > > /usr/lib/ocf/resource.d/heartbeat/IPsrcaddr > > > > Beginning tests for /usr/lib/ocf/resource.d/heartbeat/IPsrcaddr... > > > > Testing permissions with uid nobody > > > > Testing: meta-data > > > [...] [Note to myself: drop the meta-data output] > > > > ERROR: Setup problem: couldn't find command: gawk > > > > > > Install gawk perhaps? > > I am mysterious...gwak had been already installed, but this error seemed to > be given.
Sorry, it was my mistake. ocf-tester does this on purpose. > The next environment variable(OCF_TESTER_FAIL_HAVE_BINARY) of ocf-tester > seems to influence it somehow or other. > > (snip) > OCF_TESTER_FAIL_HAVE_BINARY=1 > export OCF_TESTER_FAIL_HAVE_BINARY > OCF_RESKEY_CRM_meta_interval=0 > test_command monitor > (snip) > > Similar error occurs in IPaddr2. > > [root@rh57-3 heartbeat]# ocf-tester -v -n IPaddr2 -o ip=192.168.40.8 > /usr/lib/ocf/resource.d/heartbeat/IPaddr2 > Beginning tests for /usr/lib/ocf/resource.d/heartbeat/IPaddr2... > Testing permissions with uid nobody > (snip) > Checking current state > Testing: monitor > Testing: monitor > ERROR: Setup problem: couldn't find command: ip > Testing: start > (snip) > > Is not a correction of ocf-tester necessary? > > > > > > > [...] > > > > INFO: The ip route has been already set.(192.168.40.0/24, eth0, default > > > > via 192.168.40.1 dev eth0 ) > > > > > > Hmm, I saw different stuff: > > > > > > ERROR: command 'ip route replace 10.2.13.0/24 169.254.0.0/16 dev eth0 src > > > 10.2.13.154' failed > > > > > > Debugging: > > > > > > + ip route replace 10.2.13.0/24 169.254.0.0/16 dev eth0 src 10.2.13.154 > > > Error: either "to" is duplicate, or "169.254.0.0/16" is a garbage. > > > > > > The route list: > > > > > > xen-d:~ # ip route list > > > default via 10.2.13.1 dev eth0 > > > 10.2.13.0/24 dev eth0 proto kernel scope link src 10.2.13.54 > > > 127.0.0.0/8 dev lo scope link > > > 169.254.0.0/16 dev eth0 scope link > > > > > > It seems like the last entry confuses the new calculation code. > > In my environment, I set it in NOZEROCONF=yes. > Therefore, the last entry does not exist. Right. But it's still better that the RA can handle this situation too. > > It turns out that the problem is here (nothing to do with your > > patch): > > > > NETWORK=`ip route list dev $INTERFACE scope link|grep -o '^[^ ]*'` > > > > Perhaps we should do: > > > > NETWORK=`ip route list dev $INTERFACE match $ipaddress scope link|grep -o > > '^[^ ]*'` > > > > Opinions? > > I think that the method that you showed is more right. OK. Applied that too. The ocft test passes, but cannot work without specifying the existing address. I'm not sure, but I think that ocft cannot ask for user input, so the test is going to be semi-automatic. Cheers, Dejan > Best Regards, > Hideo Yamauchi. > > _______________________________________________________ > 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/
