Sep 21, 2004
How to take down a node...
This question has come up several times since the release of 9.0 so I thought it warranted a post here. The question is about the new methods call that were previously set_state (traffic or no traffi...
You can assume that if you did not get a SOAPFault back on the request with an appropriate error code, then the call succeeded so you shouldn't have to code a check to verify that fact.
As for your question about states, it will never be MONITOR_STATUS_UP when you call with STATE_DISABLED. Disabling an object will never (as far as I know) enable that object.
With that being said, the monitor_status is a tricky beast becuase it can have multiple values after your call with STATE_ENABLED.
Here are the values of the MonitorStatus enum
MONITOR_STATUS_UNCHECKED - Status of an enabled object that is not being monitored.
MONITOR_STATUS_CHECKING - Initial status of a object until its monitors report.
MONITOR_STATUS_UP - Status of an enabled object when its monitors succeed.
MONITOR_STATUS_DOWN - Status of an enabled object when its monitors fail.
MONITOR_STATUS_FORCED_DOWN - Status of a object when it's forced down manually.
MONITOR_STATUS_MAINT - Status of an object when in maintenance mode.
MONITOR_STATUS_ADDRESS_DOWN - Status of an object whose node address monitor fails.
If you make a call to set_monitor_status() with STATE_DISABLED, it will result in a MONITOR_STATUS_FORCED_DOWN status.
If you call it with STATE_ENABLED, it's value can be one of the other values depending on the status of the monitor subsystem (whether you have monitors attached to the pool member, whether they have failed, whether the node address is down, etc). So, calling with STATE_ENABLED doesn't necessarily mean that the status will be MONITOR_STATUS_UP. It will only be MONITOR_STATUS_UP if it is enabled AND all the attached monitors succeed. STATE_ENABLED just tells the montior subsystem that it can do it's work as usual.
Make sense???
-Joe