Forum Discussion
sdevadas_82718
Nimbostratus
Nimbostratusenabling new iRule
I created a new iRule, which we can use for 'controlled blackout' conditions on our server i.e. under certain catastrophic conditions to do with our database server, we allow users who are logged in to continue and new users to not log in based on some packet inspection of POSTS in a new iRule. The details are here: http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=30684
This works well in our perf environment, and we are due to move it to production soon.
However QA noticed something which they say they cannot reproduce.
When the condition occures, we switch the iRule from the browser UI via:
Go to the virtual server -> Resources -> iRules -> click Manage button.
Here we send the old iRule to Available and enable the new rule. Once the conditions have passed, we switch back to the old (normal) rule again.
This works, but QA says that one time, the new rule did not take effect. They were not able to reproduce it however. Perf too noticed this one time, but were not able to reproduce it later. (Both times, they toggled the rules another time and things worked). I could not access their logs at the time.
Since I am not able to reproduce this condition myself: Is there a possibility that an iRule change for a virtual server may not take effect under certain conditions? Or could this be something to do with my iRule itself? In that case how did toggling the rule a second time work? I would normally have run some tests and tried to figure this out with logs, but I haven't been able to replicate this condition and hence the question.
This is not a big issue - if this is known behaviour - I will document that we need to switch the iRule twice in production (in case switching it one time does not work). Want to know if I should do this or investigate this issue further?
Thanks,
Sriram
- I've not heard of a case where things didn't take effect after iRules were switched, but I certainly haven't tested every possible scenario. Frankly if they're unable to re-produce it, I'm not going to be able to give you much of an answer, since I don't know what happened when things "failed".
That said, I'd watch for variable naming overlap, rule naming overlap, etc. to avoid any of the obvious possibilities. They shouldn't cause any issues, but erring on the safe side isn't bad. Other than that I think you'll be fine. If you ever do find a way to reproduce it we might be able to track down what's causing the issue, so let us know.
Colin 
sdevadas_82718Thanks Colin. You are right. I think I posted too soon. Perf clarified that the case was due to using the incorrect version of the iRule. The mechanism passed the perf tests and is ready on the production environment.
Will post when (and if) we do use this 'blackout' rule in production (we expect the condition to occur again, if it does, under high loads) - and we face any issues.- sdevadas_82718Hi Colin,
We had a chance to use this 'blackout rule'. Our database locked up in production yesterday and we turned on the blackout rule to keep existing sessions while redirecting new logins based on packet inspection.
Everything worked.
Thanks,
Sriram
