Automating APIs with Python & Go (Part II)

Automating APIs with Python & Go (Part II)

Chris EvansCode

This is the second of a series of posts covering automating APIs with Python and Go.  This post continues the discussion of building a CLI to manage my Scale Computing HE150 lab cluster.


I’ve spent some more time developing the Python code for pulling virtual machine data back from my HE150 cluster.  At this point, I’m thinking of developing each Python module as a separate file, covering the functions needed to operate a cluster.  However, for the code I develop in Go, I’m looking at a single executable. 

Why the difference, you might ask?  As I get back into writing code, creating separate Python modules seems a more manageable approach to take.  Figure 1 shows a quick mind map of the API calls available on the Scale HC3 platform, divided up by function type.  It’s easy to see that there needs to be (for example) functions that list VMs, functions that create/destroy/clone VMs, functions that work on clusters, functions that display miscellaneous settings and functions to manage users. 

Figure 1: Scale API Map

As I haven’t fully decided on the command structure, having separate modules provides some flexibility as I translate CLI commands to API capabilities. 


For the code developed in Go, I’m taking a different approach and building a single executable.  That code is likely to take longer to develop but use the flow from the Python modules and a single command syntax.  So, expect to see the Python code first, then the Go code later.


One question I think worth answering is why a CLI interface makes more sense than API.  Obviously, it’s entirely possible to automate using the API; however, at some point, there needs to be some logic in place to combine multiple API calls.  For example, cloning a VM requires taking a snapshot from the source machine and using that snapshot to create the new VM.  There’s no “clone” API call.  If I were building this capability within some automation framework like Ansible or Chef, then I’d still need some logic somewhere.  That logic may as well be built into the CLI. 


The initial code for listing VMs has now changed somewhat.  I’ve added parameters for showing command help and version details.  User name, password and cluster name can all be specified on the command line, or through environment variables.  If neither is specified, defaults are used.  (Note: I will likely change this to fail if neither environment variables or parameters are specified, but for now and for testing, defaults are in place). 

This version of the code now uses basic authentication, which is simply a combination of user name and password separated by a colon and converted into base64.  There’s an in-built Basic Auth header generator available the requests module that handles this automatically.  This is one of the nice aspects of platforms like Python.  There’s usually a module or code library available for commonly used functions. 


I’ve uploaded this first code ( to a GitHub repository – where anyone can download the content and use freely.  I’ll try and create something a bit more substantial before posting again, probably once the command structure is developed. 

Post #5166. Copyright (c) 2007-2020 Brookend Ltd. No reproduction in whole or part without permission.