Forum Discussion
candc
Cirrus
CirrusRemoving the 'reject' keyword from a virtual, using TMSH / iApp
I have an iApp which creates a virtual server. Depending on one of my iApp choices, this is either configured as a normal load-balancing virtual server (displayed as "Standard" in the web GUI), or to...
What is the reasoning for using a explicit "reject" virtual server in this case? Can you not have the virtual not exist unless you need it? That would be the simplest way to handle this case and most standard. The problem for you here is that once you specify reject, even if your modify statement(which is what the iapp framework turns the create into after the initial save) does not contain the reject keyword unless something else is specified to override it then it wont go away.
For example specifying ip-forward will cause reject to go away and it will become a forwarding virtual server.
candcCirrus
CirrusIt's only a value-add if it is the desired behaviour at the time.
The reason I want to be able to disable the node and abort open connections, is that this particular virtual server acts as a site-wide probe target for another upstream load balancer (outside of my control).
That device uses a long-poll mechanism, so the connection is maintained through the enable/disable configuration.
There is no pool behind the server, it merely points to an iRule which implements a rudimentary echo server. I don't really want to have to implement dropping the connection from within the iRule.
I have gone with with simply deleting the virtual server for now but, for review purposes, I would've preferred the virtual server was there but explicitly disabled, rather than missing and possibly forgotten.