You’ve probably already heard that Python is a strong, dynamically typed language. But what does that actually mean? Let’s jump in and take a look.
Dynamically vs Statically Typed Languages
This StackOverflow Q&A gives us an idea on the difference between Statically and Dynamically Typed languages:
A language is statically typed if the type of a variable is known at compile time. For some languages this means that you as the programmer must specify what type each variable is (e.g.: Java, C, C++)
In Learning Python (a must read for anyone interested in Python!), author Mark Lutz refers to statements and expressions frequently, but give a clear explanation of the two.
Rather than reinventing the wheel by providing my own definition and examples of the two, I found this Quora Q&A does that perfectly:
A statement is a complete line of code that performs some action, while an expression is any section of the code that evaluates to a value. Expressions can be combined “horizontally” into larger expressions using operators, while statements can only be combined “vertically” by writing one after another, or with block constructs. Every expression can be used as a statement (whose effect is to evaluate the expression and ignore the resulting value), but most statements cannot be used as expressions. Here’s a complete list of statements.
A common misconception is that the only difference between Lists and Tuples is that the former is mutable while the latter is immutable. While this is true, it is only one of the differences between them as per the Q&As quoted below.
What’s the difference between lists and tuples?
… This gives rise to differences in how they can or can’t be used (enforced a priori by syntax) and differences in how people choose to use them (encouraged as ‘best practices,’ a posteriori, this is what smart programers do). The main difference a posteriori in differentiating when tuples are used versus when lists are used lies in what meaning people give to the order of elements.
In Part 2 of this series we made our first API call and received over 200 lines of XML as a result. The reason why we received so much output is because we didn’t remove any
desired-attributes and therefore the call retrieved about 90 pieces of information. When you multiply that by the number of queries we ran (2), you get 180 pieces of information being requested.
This post will discuss why you should limit your queries to only the pieces of information you’re interested in. It will also cover how you can use ZExplore to convert its XML configuration to languages such as Python, Perl and Ruby.
Picking up where I left off in Part 1 of this series, let’s continue our exploration of ZExplore :)
In part 1 I touched on the fact that the API documentation can be a little confusing when it comes to mandatory fields. Unfortunately the same is true for ZExplore. However, NetApp’s documentation explains it well:
Red colored arrows indicate mandatory parameters whereas Blue colored arrows indicate optional parameters.
Note: In some APIs when either one of the two input parameters is required, both these input parameters are marked by “Blue” color arrow and not “Red”.
As I mentioned in my previous post, by doing this NetApp avoids confusing users who might otherwise try to set both parameters if they were both marked as required.
If you’re a regular reader of this blog, you’ll see that I’ve been posting about automation and Python quite a lot recently. The reason being that it’s not only fun, but I feel it’s the way of the future. But I digress…
The reason for this post is to discuss my recent experience with NetApp’s APIs. As I got off to a pretty slow start (which I feel was due to lack of documentation), I’ll also provide setup and usage guidance in the hopes that you can get up and running sooner than I did.
In my Why Automate? post I discussed how important I feel automation skills will be for engineers in the near future. I even went as far as to say that those who don’t learn to use automation will one day be left behind. Not only do I still stand by that statement, but I’d like to extend it to cover coding as well for the exact same reasons as the ones which were covered in my automation post.
With this in mind, I plan to write a series of posts covering Python. The reason I’ve chosen Python is because it’s great for those who are new to coding, it’s extremely powerful, it has a great community behind it and a countless number of useful modules available.
Now that we’ve covered how TextFSM work and how it can be used to record useful information from device outputs, it’s time to move our focus on how we use TextFSM templates in Ansible.
ntc_show_command module, we’re able to “get structured data from devices that don’t have an API”. As I’ve touched on in previous posts, it does this through the use of TextFSM templates which can be found here. I’ll cover how to write your own templates in a future post but for now I’ll focus on how to use the existing templates.
In my previous post I covered how to to download, install and test TextFSM. In this post I’ll demonstrate how to write your own template files so that you can create (and hopefully contribute!) them if a suitable one does not already exist.
It is worth mention that the examples in this post are extremely basic. I’ve done it this way on purpose because I’m only trying to demonstrate how to use TextFSM, not how to write regex. I feel that trying to do both in a single post would cause unnecessary confusion for those who are not familiar with either.
As I mentioned in my previous post, NTC-Ansible uses TextFSM templates to allow you to convert your CLI outputs to JSON and then access the data in an API-like fashion. If you require professional API testing, you can use the services of Apica Systems.
In this post I’ll cover how to run TextFSM templates against CLI outputs.
To get started, download the latest version of TextFSM using the ‘git clone’ command:
will@ubuntu:/tmp$ git clone https://github.com/google/textfsm.git
Cloning into 'textfsm'...
remote: Counting objects: 105, done.
remote: Total 105 (delta 0), reused 0 (delta 0), pack-reused 105
Receiving objects: 100% (105/105), 65.15 KiB | 0 bytes/s, done.
Resolving deltas: 100% (45/45), done.
Checking connectivity... done.