Getting Started with the f5-common-python SDK
If you have dabbled with python and iControl over the years, you might be familiar with some of my other “Getting Stared with …” articles on python libraries. I started my last, on Bigsuds, this way:
I imagine the progression for you, the reader, will be something like this in the first six- or seven-hundred milliseconds after reading the title: Oh cool! Wait, what? Don’t we already have like two libraries for python? Really, a third library for python?
It’s past time to update those numbers as the forth library in our python support evolution, the f5-common-python SDK, has been available since March of last year! I still love Bigsuds, but it only supports the iControl SOAP interface. The f5-common-python SDK is under continuous development in support of the iControl REST interface, and like Bigsuds, does a lot of the API heavy lifting for you so you can just focus on the logic of bending BIG-IP configuration to your will. Not all endpoints are supported yet, but please feel free to open an issue on the GitHub repo if there’s something missing you need for your project. In this article, I’ll cover the basics of installing the SDK and how to utilize the core functionality.
Installing the SDK
This section is going to be really short, as the SDK is uploaded to PyPI after reach release, though you can clone the GitHub project and run the development branch with latest features if you so desire. I'd recommend installing in a virtual environment to keep your system python uncluttered, but YMMV.
pip install f5-sdk
A simple one-liner and we're done! Moving on...
Instantiating BIG-IP
The first thing you’ll want to do with your shiny new toy is authenticate to the BIG-IP. You can use basic or token authentication to do so.
I disable the certificate security warnings on my test boxes, but the first two lines in the sample code below are not necessary if you are using valid certificates
>>> import requests
>>> requests.packages.urllib3.disable_warnings()
>>> from f5.bigip import ManagementRoot
>>> # Basic Authentication
>>> b = ManagementRoot('ltm3.test.local', 'admin', 'admin')
>>> # Token Authentication
>>> b = ManagementRoot('ltm3.test.local', 'admin', 'admin', token=True)
>>> b.tmos_version
u'12.1.0'
The
btmos_versionNomenclature
The method mappings are tied to the tmsh and REST URL ids. Consider the tmsh command
tmsh list /ltm poolb.tm.ltm.pools
If there is a collection already ending in an s, like the subcollection of a pool in members, it would be addressed as members_s. This will be more clear as we work through examples in later articles, but I wanted to provide a little guidance before moving on.
Working with Collections
There are two types of collections (well three if you include subcollections, but we’ll cover those in a later article,) organizing collections and collections. An organizing collection is a superset of other collections. For example, the ltm or net module listing would be an organizing collection, whereas ltm/pool or net/vlan would be collections. To retrieve either type, you use the
get_collection
# The LTM Organizing Collection
>>> for x in b.tm.ltm.get_collection():
... print x
...
{u'reference': {u'link': u'https://localhost/mgmt/tm/ltm/auth?ver=12.1.0'}}
{u'reference': {u'link': u'https://localhost/mgmt/tm/ltm/data-group?ver=12.1.0'}}
{u'reference': {u'link': u'https://localhost/mgmt/tm/ltm/dns?ver=12.1.0'}}
# The Net/Vlan Collection:
>>> vlans = b.tm.net.vlans.get_collection()
>>> for vlan in vlans:
... print vlan.name
...
vlan10
vlan102
vlan103
Working with Named Resources
A named resource, like a pool, vip, or vlan, is a fully configurable object for which the CURDLE methods are supported. These methods are:
- create()
- update()
- refresh()
- delete()
- load()
- exists()
Let’s work through all these methods with a pool object.
>>> b.tm.ltm.pools.pool.exists(name='mypool2017', partition='Common') False >>> p1 = b.tm.ltm.pools.pool.create(name='mypool2017', partition='Common') >>> p2 = b.tm.ltm.pools.pool.load(name='mypool2017', partition='Common') >>> p1.loadBalancingMode = 'least-connections-member' >>> p1.update() >>> assert p1.loadBalancingMode == p2.loadBalancingMode Traceback (most recent call last): File "", line 1, in AssertionError >>> p2.refresh() >>> assert p1.loadBalancingMode == p2.loadBalancingMode >>> p1.delete() >>> b.tm.ltm.pools.pool.exists(name='mypool2017', partition='Common') False
Notice in line 1, I am looking to see if the pool called mypool2017 exists, to which I get a return value of False. So I can go ahead and create that pool as shown in line 3. In line 4, I load the same pool so I have two local python objects (p1, p2) that reference the same BIG-IP pool (mypool2017.) In line 5, I update the load balancing algorithm from the default of round robin to least connections member. But at this point, only the local python object has been updated. To update the BIG-IP, in line 6 I apply that method to the object. Now if I assert the LB algorithm between the local p1 and p2 python objects as shown in line 7, it fails, because we have updated p1, but p2 is still as it was when I initially loaded it. Refreshing p2 as shown in line 11 will update it (the local python object, not the BIG-IP pool.) Now I assert again in line 12, and it does not fail. As this was just an exercise, I delete the new pool (could be done on p1 or p2 since they reference the same BIG-IP object) in line 13, and a quick check to see if it exists in line 14 returns false.
The great thing is that even though the endpoints change from pool to virtual to rule and so on, the methods used for them do not.
Next Steps
This is just the tip of the iceberg! There is much more to cover, so come back for the next installment, where we’ll cover unnamed resources and commands. If you can't wait, feel free to dig into the SDK documentation.
Updated Jun 06, 2023
Version 2.0
JRahm
Admin
Admin
F5_Digger_13600Cirrus
Hi Jason,
I tried to get the list of policy-strategy from BIG-IP 12.1.2 and noticed that current python SDK doesn't provide a wrapper function for that.
Does it sound right?
I just want to make sure this is not supported through Python SDK yet.Thank you.
Can you open an issue on GitHub for that and I'll take a look?
- F5_Digger_13600
Will do. Thank you Jason.
Joel_42834Nimbostratus
Jason,
I just looked at the changes for obtaining the HA failover status of a node.
Here's what I was able to come up with:
mgmt = ManagementRoot(host, username, password)
xx = mgmt.tm.cm.failover_status.load()
print(xx.attrs['entries']['']['nestedStats']['entries']['status']['description'])
'ACTIVE'
Is there an easier way to get this information?
Thanks,
Joel
- JRahm
Hi Joel, yes, using the Stats utility makes this a little cleaner:
>>> from f5.utils.responses.handlers import Stats >>> x = Stats(b.tm.cm.failover_status.load()) >>> x.stat['status']['description'] u'ACTIVE' - Joel_42834
Thanks Jason, I'll give it a try.
I would suggest that you need to be thinking about cleaner interfaces as well the customer view.
An SDK is supposed to make getting this information easy/trivial.
I would have expected this:
b.tm.cm.failover_status.load()['status']['description']
Joel
- JRahm
We try to make sure the methods themselves are "dumb" and do what the interface intends, and fix some methods that are out of standard from other normal behaviors. Stats were changed from 11.6 - 12.0 pretty significantly, and whereas the Stats utility isn't as robust as it should be yet, it allows us to honor the goals for methods while providing options for the nightmare you posted.
That said, feel free to open an issue on GitHub for stats object kinds and suggested options on how to handle that and we'll discuss.
Maybe an alternative in the load method is to pass a kwarg for Stats, or just an alternative load method called load_stats()?
- Joel_42834
I guess the question is whether "stats" is for statistics or status.
IMHO, the failover state is a status and not a statistic and therefore, it should be a direct attribute of an object.
RANT WARNING
As for whether SDK methods should be "dumb", I would suggest that that is not the purpose of an SDK. An SDK should provide a view of the system that makes sense independent of the transport mechanism. Whether the SDK methods are "dumb" or not should be driven by the functionality of what the method is trying to do for the user.
My experience with this SDK is that it is a thin layer above the REST API. This view is supported by the SDK documentation which really is a description of how to map the SDK's Python objects to the REST API. This is further supported by the numerous references to URIs throughout the documentation. From a Python perspective, the URIs don't belong in the documenation. They are an implementation detail and not a functional one.
The fact that it is using a REST API, a SOAP API or some other proprietary protocol is irrelevant to me. I simply don't care. I care about getting stuff done on the LTM. And the SDK should present a view of the system that makes sense from a Python perspective.
And the SDK should be focused on that. And I don't think it is. Instead it is focused on presenting the REST API with as little work as possible.
I come from the world of TMSH. I never learned the REST API. My expectation with the SDK was that I wouldn't have to.
END OF RANT
- JRahm
Hi Joel. I'm not sure why non-stats are returned as stats in some endpoints, but that's the way the REST interface is currently. The decision on the sdk team was to not create all the one-offs that would have been required to make it seamless across the interface.
Having used and participated in the development of the sdk, I happen to like it a lot and it's been very helpful for me in cutting down the amount of code I need to write. However, I understand the frustration and you have some very valid arguments, so no worries on the rant! The sdk itself (I think, I joined after the structure was decided upon) was started as an iterative stepping stone for building declarative models with tools like Ansible, so whereas we benefit from its existence, I'm not completely sure the original intent was for it to be consumed directly.
We will discuss your feedback. We are always open to feedback like this, and if you have suggestions on how this (or another library entirely) can be improved, how you would like to consume the interfac, etc, we'd be glad to have that discussion.
Muhammad_64435Jason, great article and awesome SDK ... i just fall in love with it.
I am working on migrating sites from one 'old' unit to the new one. Plan is to read the following information from the Old unit :
- Virtual Server
- Pools
- Persistence profile
- SSL Profile
- Data Groups
- iRules etc.
and create a script to re-create them ditto on the new unit.
So far I have developed the Virtual Server script and wondering if you can see if its the right way of doing it :
from f5.bigip import ManagementRoot import getpass mgmt = ManagementRoot(BigIP_IP, "admin", "pass") print ("===Create a Virtual===") vip = mgmt.tm.ltm.virtuals.virtual.create(\ name='testvip',\ partition='Common',\ destination='10.10.10.10:80',\ ipProtocol='tcp',\ sourceAddressTranslation={'type': 'automap'},\ persist=[ { 'name': 'testvip-Cookie' } ],\ rules=["testvip-rules"],\ profilesReference={ 'items' : [ { 'name' : 'http_XForwardedFor' }, \ {"name": "oneconnect"},\ {"name": "tcp-lan-optimized", "context": "serverside"},\ {"name": "tcp-wan-optimized", "context": "clientside"},\ {"name": "testvip-clientssl-ssl"} ] } )But one thing I couldn't able to do is how to disable the above VIP. I mean "state"="disabled". I tried disabled = 'true' but it errors out.
Second, I need to modify the virtual-address attached to the above testVIP (10.10.10.10) to disable "arp" and "icmpEcho" and change the traffic-group but I couldn't able to even check if it exists :
vip = mgmt.tm.ltm.virtualAddress.exists(name='10.10.10.10', partition='Common')It keeps giving an error
AttributeError: '' object has no attribute 'virtualAddress'Please let me know what I am missing or doing wrong.
Highly appreciate your help.
Thank you,
Muhammad
