Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Handling Differences in v11/v12 in Python SDK for iControl REST

We're interested in using the f5 SDK (version: 3.0.18) to replace several cURL scripts that manage our LTM and GTM pools. One of the major draws here is that the SDK provides sufficient abstraction to work with the target API irrespective of iControl REST version (my cURL scripts need separate methods for v11 and v12 destinations):

Between the 11.x and 12.x releases of BIG-IP, the REST endpoint for Pool changed from a Collection to an OrganizingCollection. The result is that breaking changes occurred in the API.... To stick with a consistent user experience, we decided to override the __new__ method to support both examples above. The SDK automatically detects which one to use based on the BIG-IP you are communicating with.

(https://f5-sdk.readthedocs.io/en/latest/apidoc/f5.bigip.tm.gtm.html#f5.bigip.tm.gtm.pool.Pools)

In practice, we haven't seen this autonegotiation. Using the SDK, we've still had to employ different code to list pool and members, eg, in v11 and v12:

v11 code:

from f5.bigip import ManagementRoot
# This first block works in v11, but not v12.
print ("Getting pools with v11 syntax...")
mgmt = ManagementRoot('@option.GTM_Server@', '@option.F5_User@', '@option.F5_Password@')
api_ver = mgmt.tmos_version
pool_collection = mgmt.tm.gtm.pools.get_collection()
pools = mgmt.tm.gtm.pools

for pool in pool_collection:
    print ("Querying state of pool %s members...") % (pool.name)
    for member in pool.members_s.get_collection():
        print ("Pool member name: %s") % (member.name)
        print ("Ratio: %d") % (member.ratio)

Executing v11 code against a v12 API returns expected errors:

Getting pools with v11 syntax...
Traceback (most recent call last):
<snip/>
    print ("Querying state of pool %s members...") % (pool.name)
AttributeError: 'dict' object has no attribute 'name'`

v12 code:

from f5.bigip import ManagementRoot
# This first block works in v12, but not v11.
print ("Getting pools with v12 syntax...")
mgmt = ManagementRoot('@option.GTM_Server@', '@option.F5_User@', '@option.F5_Password@')
api_ver = mgmt.tmos_version
pools = mgmt.tm.gtm.pools.a_s.get_collection()

for pool in pools:
    print ("Querying state of pool %s members...") % (pool.name)
    for member in pool.members_s.get_collection():
        print ("Pool member name: %s") % (member.name)
        print ("Ratio: %d") % (member.ratio)

Executing v12 code against a v11 API returns expected errors:

pools = mgmt.tm.gtm.pools.a_s.get_collection()
  File "/usr/local/lib/python2.7/site-packages/f5/bigip/mixins.py", line 102, in __getattr__
    raise AttributeError(error_message)
AttributeError: '<class 'f5.bigip.tm.gtm.pool.Pools'>' object has no attribute 'a_s'

I'm not a Python programmer and will readily accept the likelihood that I'm just doing it wrong in code. Can we use the same code against different versions of the API using the SDK?

Thanks.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi @syncretism, this is honestly an area where I think we made it harder for the end user by sticking to the sdk design requirements of honoring the REST API endpoints. Because they changed so dramatically between v11 and v12, it's going to require using both methods to interact with the different TMOS versions. So for v11, it would be:

mgmt_root.tm.gtm.pools.pool.create(name=....)

and for v12 (for an a record):

mgmt_root.tm.gtm.a_s.a.create(name=...)

you can substitute the other methods as necessary.

1
Comments on this Answer
Comment made 5 months ago by syncretism 75

Hi, @Jason Rahm,

Thanks very much for your prompt reply. Is it fair to say, then, that we need to code for v11 separately from v12? Effectively a "case" based on the API version (which is what I'm doing with cURL)? I just want to ensure I understand that when I'm evaluating the approaches. Thanks again!

0
Comment made 5 months ago by Jason Rahm

for now, yes. I'd like to propose a change to the sdk development team to make the sdk responsible for handling the v11/v12 cases on the behalf of those using the sdk. It shouldn't be this hard.

1
Comment made 5 months ago by Jason Rahm

You can track any progress against this issue on Github.

1