Forum Discussion
I confirmed 100% what you stated about rule order. It appears you have to append it and the error just isn't very clear about what it wants.
It appears there are really 2 kinds of priorities (order of listing in the gui and actual coded priority which overwrites the list order afaik) There is only one priority list, the GUI simply obfuscates it from the user. I think it's important to note here that the BigIP GUI uses iControl; essentially everything that the GUI is showing you was obtained through a very complicated iControl program What I don't understand is why the API cares the least in what order I add any of my rules considering that each rule could have a priority set within it which makes the listing order irrelevant. I tested this and can confirm it: When I have 5 pre-existing rules and I add my maintenance rule with priority 100 it appends it. Yet the rule itself is actually set to p1. A quick tmsh show ltm rule {rulename} confirms that the rule is at p1 eventhough it was inserted at p100 so in my mind the p100 just got replaced with a p1 no ?So given that :
1. I _have_ to append the rule to the end of my rule stack 2. I can set any priority within the rule and it will winI'd have to test that, your experience does seem counter-intuitive. My expectation would be that if you set priority 100 on a virtual with 5 rules, that the priority 100 iRule would become p5 (0 - 4 already existing)
I see no point in the API forcing me to set what appears to be an arbitrary number at rule association time.iRule priorites aren't arbitrary. The list order in the GUI, and the TMSH order from the config are VERY signifigant. iRule processing happens in the order they are shown in both TMSH and in the GUI, The reason the priority order is important, is for the reasons I described in my first reply. In your case, it may not be important, as you are setting up a redirect response, however, if you were doing something like, say.. attempting to control a persistence record or pool declaration in two different iRules, your results may depend on the last iRule that fired (the iRule with the highest priority number).
I'll test the scenario you've given to see if I come up with similar results, if so, then it is something that should be handled within support. If not, I'll see if we can come up with an explanation for what you are seeing.
As to your other suggestion I did think about that for a bit but I have some issues here:1. If I remove the current rule set where do I save it ? I'd have to have a way to save state somewhere and then restore it. I assume you mean to save the entire b config on the unit and then restore it once maintenance is over ?
iControl applications aren't typically interactive in this way. if you were writing an application that uses the BigSuds library (something I don't have a lot of experience with) I would imagine that you would do something like this:
// Please forgive me if my Python syntax is wrong. I am VERY rusty with python...
1. virtualname = '/Common/test'
2. rule_list = lb.LocalLB.VirtualServer.get_rule([virtualname]) //Here we are saving the rule list in a variable to be reused later
3. // This is where you would look for the highest priority order, add the new rule, and change the existing priority orders
4. lb.LocalLB.VirtualServer.remove_all_rules([virtualname]) // This removes the existing rules, so that our new priorties don't conflict with the existing ones
5. b.LocalLB.VirtualServer.add_rule([virtualname],[rule_list]) // Here we are reloading the list that we saved earlier, with the changes you made in step 2.
Seems a bit extreme in my opinion. I also wouldn't wanna save something to my desktop from where I'm running bigsuds so I'm a bit unclear how you'd approach that.
2. I simply feel uncomfi making any more changes than I have to especially being very new to icontrol and python so this doesn't feel like the right choice.
3. I don't see why my current solution of appending a P1-coded maint irule to a pre-existing list would not be ok. It works very well so far. In the gui it shows up last but it is reported as P1 under tmsh. I mean once it's hit it redirects to another site anyway so the other 5 rules don't kick in to begin with so I couldn't care less about them while the site is in maintenance.You're solution may be OK for you. I just wanted to call out that this may not be the appropriate solution for every circumstance considering the impact rule priority has on iRules stepping over each other.
The extreme nature of my proposed solution was to identify a way of changing the priority order, if it is neccessary, again, in your case it may not be.