Forum Discussion
Brent_West_7733
Mar 03, 2013Historic F5 Account
Posted By stucky101 on 03/02/2013 09:08 PM
Joe
I have some news (good news !)
I realized that pycontrol is already out the window and it's on to bigsuds. I must say bigsuds is an improvement ! I like it. I was able to work out the syntax to add an irule in bigsuds without any helper function:
lb.LocalLB.VirtualServer.add_rule(['/Common/test'], [[{'rule_name':'/Common/api_maintenance', 'priority': 1}]])
The API could use some more clarity here to be honest - I pieced this together and it took longer than it should have but that aside...
However, the same problem persists. Then just for giggles I changed the priority to 2 and guess what ? It works !
It also works with other numbers but as soon as you try 1 again it bails when there are already 2 rules bound.
Bug in the API ?
Not sure I care too much since 2 does the trick just fine assuming nobody created a normal rule with P1.
Wanted to share that...
I'll take a stab at this...
Since you already have iRules associated with the virtual server, you can't "insert" a new rule in front of the existing priority order, you must "append" a rule to the end of the list. I believe that when you insert a rule with a priority that is out of range, it reorders the priority to the next available number, so... you could technically add a rule with a priority of 99, and unless you had 99 rules it would append the rule to the end of the list with the next available number.
Additionally, you may be unsatisfied with the results of simply adding a rule to the end of the list. The reason for the priority is that each iRule fires in order, and if there are conflicting results...
i.e. you have two iRules that use when HTTP_REQUEST... both set the destination pool based on a URI... the last rule to fire wins, and could "undo" the results of the lower priority rule.
The correct way to do this, placing the rules in the desired order, would be:
1. "get_rule"
2. modify the rule names and priorities in the resulting array from "get_rule"
3. "remove_all_rules"
4. "add_rule" with the new array from step 2.
As an added safety measure, if you are using BigIP version 11 or higher, you could do all of this within the context of a transaction, that way if any step fails, the entire transaction is rolled back and no modifications are made, leaving your existing rule set intact, for example if you added an invalid rule name or a duplicate priority number. This certainly takes a lot of worry out of the "remove all rules" command!
If you simply want to append an iRule to the end, you would do a "get_rule", progrmatically find the highest priority number, add 1, and then "add_rule" with the correct array syntax.