Forum Discussion
Brent_West_7733
Mar 03, 2013Historic F5 Account
I thought about it a little more, perhaps this what you mean...
If you were to use my code above, without step 2, you would be adding back the list exactly as the API gave it to you, with the same rule names and same priority orders
the results of
rule_list = lb.LocalLB.VirtualServer.get_rule([virtualname])
may look something like this:
{{'rule_name': 'rule_0', 'priority':'0', {'rule_name': 'rule_1', 'priority':'1'}, {'rule_name': 'rule_2', 'priority':'2'}}
The reason that you have to have the 'priority' key in a python dictionary is that when the rule_list dictionary is enumerated by Python, it may return the list to iControl like this:
{{'rule_name': 'rule_2', 'priority':'2'}, {'rule_name': 'rule_0', 'priority':'0'}, {{'rule_name': 'rule_1', 'priority':'1'}}
This is how is inherent in the way Python works. (Perl as well). Associative arrays (Python calls them dictionaries, perl calls them hashes) don't return in the same order that they are stored. You can sort an array(dictionary, list), but the next time you try and recall it, it is again unsorted; it's just the way the underlying coding languages work. Instead of a variable, you could do the same:
lb.LocalLB.VirtualServer.add_rule([virtualname], [{{'rule_name': 'rule_2', 'priority':'2'}, {'rule_name': 'rule_0', 'priority':'0'}, {{'rule_name': 'rule_1', 'priority':'1'}}])
and when I control received it, it would be in a random order, which is why we have to specify the priority number at association time.