Hi, On 23-Nov-10, at 3:52 AM, Andrew Beekhof wrote:
>> Another question -- is it possible to define resources that do not >> have stop actions? On AWS, there is no need to explicitly stop an >> elastic IP before reassigning it to another node (the IP will be >> automatically released from a host before it is assigned to another). > > By who? > On AWS, hosts are directly (as shown by ifconfig) assigned only non- routable 10/8 addresses. These are aliased to routable IPs using some sort of NAT magic. Switching an elastic IP from one machine to another therefore doesn't involve changing anything in the network stacks of the actual hosts. Instead, only the NAT table maintained by Amazon is updated. If you're curious, here's Amazon's explanation: http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?concepts-instance-addressing.html >> >> I've played around a bit with making the stop action in the resource >> script be a no-op that always returns OCF_SUCCESS. This seems to >> work, but I can imagine that there will be situations where Pacemaker >> may get confused (a call to "monitor" will show a resource is still >> running, even though an immediately prior call to "stop" returned >> success). > > Yep, that's the downside of a no-op. > Does it really take so long to remove the IP? > Not usually. The problem is, unlike a simple "ifconfig ... down", the script has to do something like this: disassociate_address(ip) while (describe_address(ip) == host) { // IP still shows as associated to this host. // Keep looping until the IP shows as no longer associated. } The disassociate API call is consistently pretty fast. However, the while loop where we wait for the IP to show as disconnected from the host can take a variable amount of time to exit -- sometimes even a minute or two. Since the disassociate step is basically optional, I wanted to leave it out to avoid that potential 1-2 min delay. -- Andrew _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
