v11/v10 iControl get_list change in behaviour? (/Common prefix)

Hi Samstep,

 

 

There is no functionality change on get_list() between v9, v10, and v11. It still works the same. The difference is on v11 itself. In order to add some configuration functionality (I suspect) they have now added the Partition to the Object Name. Basically everything now has it's partition appended to it, so now you can have iRules, Pools, Virtual Servers, etc. with the exact same name in different partitions because they are made distinct by the Partition Name.

 

 

This is because partitions are now literally split into different bigip.conf files instead of one file to rule them all. So the Common Partition is in /config/bigip.conf, but anything else is in /config/partitions//bigip.conf.

 

 

Hope this helps.

Hi Samstep,

 

As you see there was a fundamental change in object keys, and part of the effect of that was to change what comes back from get_list and other methods that return names of (most) objects. (Other effects required us to deprecate a few entire interfaces because most keys that stil were not strings were made strings). We weighed the issue and tradeoffs and decided to make the query methods return the full name of the object including folder path. The new world includes folders, potentially with names that would look duplicate and cause havoc if you strip the path off, so we decided to make the new (and actual) name be the default, changing the behavior in a major release, 11.0, rather than making the default the stripped path and changing it later (what might look like: capriciously) down the road.

 

There is a workaround we put in to strip the path information if it caused people hardship but we decided not to make that the default for various reasons. The workaround you can try is the {set,get}_returned_path methods in System:Session. One interesting thing about that is the Session is persistent (by default on user id) so you can even run a separate request to set this and then run your normal code if you really needed to do it that way. Please be aware this is a workaround and is not intended as a general tool for stripping the path in ongoing new development; (most of) the objects have a path now and that's the new world to get used to. Also, there were a couple places in initial releases we missed respecting the ReturnedPath setting; those are fixed now. Sessions, by the way, are generally intended (in part) as a way to accomplish a given task with a bag of settings and still retain backwards compatibility for the most part; in particular they aren't persisted in anything but memory.

 

My apologies for the irritation you're experiencing -- I'd like to ask, what kind of processing are you doing on the name that has trouble tolerating the path? There are some scenarios that can show ill effect, like one might create a pool, then malfunction if one does not find exactly what one set on subsequent query; I'm curious as to what your code does.

 

Many thanks for your response Todd,

 

 

I have indeed found out that to get back to "normal" behaviour to provide compatibility I need to call:

 

System::Session::set_returned_path(PATH_BARE)

 

...at the beginning of the session.

 

 

My code was checking the list of objects on the BIG-IP against the list of created objects on several BIG-IPs with a mixture of versions 9/10 and 11. So I create a pool called "PoolABC" on 3 BIG-IP devices with different versions (v9/10/11) and when I check the list of pools v9 and v10 devices return "PoolABC", however v11 returns "/Common/PoolABC" . as a result the business logic validation fails on v11 because the returned name of the created object by the API is different form the name of the object that was created!

 

 

I understand the whole "New World" concept, however...my frustration comes from the fact that the DOCUMENTATION of get_list() method in iControl API does not mention that the returned list will contain the folder name starting from version 11. It really needs to be updated to reflect the change in the returned data

 

 

Thanks,

 

Sam

 

 

 

Yes, I understand. At a guess there are maybe 600 methods for which we could add such documentation (get_list plus all the methods that return a key to an object with a path in the name) -- it's unfortunate that iControl is not structured in such a way as to make it easier to handle getting the word out for this sort of thing. It's possible putting the same documentation in each of these methods would actually detract from the usability of our documentation; something to ponder. Do you read the release notes? Perhaps such a place would be a better place to put stuff like this, but I'm skeptical of how many people would find this in a release note. In this case, it's a judgement call, and I can see it led to frustration for you. We try to avoid behavior changes as much as possible.

 

 

So above you said: "when I check the list of pools" above . . . I know that they would not match if not using PATH_BARE (and please remember, that's not meant for ongoing development); I'm still curious - can you tell me just so I understand, why your code is checking the name vs what you created? I just want to understand the scenario, since we figured it would not be the most common case.

I have run into a similar problem:

 

./LocalLBPool.pl host_name 443 username passwd /APPLICATION/xxx.xxx.xxx.xx_443

 

and it failed.

 

In the ltm log, I saw this error:

 

Sep 13 17:06:04 slot1/host_name err mcpd[7389]: 01020036:3: The requested pool member (/APPLICATION/xxx.xxx.xxx.xx_443 /Common/172.18.241.10%1 https) was not found.

 

Why did the system assume the node/pool member was in /Common?

 

I do read release notes, and I do read all bug lists before I want to adopt any new functionality.