Openstackclient is better than I thought

June 28, 2015 David Moreau Simard

4 minute read

When openstackclient came out, I was not a believer. I thought.. Great, a new standard (cue XKCD), and I joked about it.

I had been using the ordinary CLI clients like novaclient, keystoneclient and so on. Over time, I guess I got used to their strengths, weaknesses and their quirks for better or for worse.

We’ve started wrapping around Openstackclient in the different puppet modules for Openstack. Since Openstackclient provides CSV output, it makes it easy for us to parse the command outputs.

This prompted me to look closer at Openstackclient as I needed to develop features that would leverage it.

The objective of Openstackclient

OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Object Store and Volume APIs together in a single shell with a uniform command structure.

The primary goal is to provide a unified shell command structure and a common language to describe operations in OpenStack.

Version 1.0 of Openstackclient was released on December 4th, 2014. Let’s look if Openstackclient has had time to deliver on that promise.

The openstack clients inconsistencies addressed

Show a virtual machine instance ?

# This one is easy enough...
nova show <instance>
# With openstackclient:
openstack server show <instance>

Show an aggregate ?

nova aggregate-show <aggregate>
error: argument <subcommand>: invalid choice: u'aggregate-show'
# Oh.. right, it's aggregate-details
nova aggregate-details <aggregate>
# With openstackclient:
openstack aggregate show

Show a user ?

keystone user-show <user>
keystone: error: argument <subcommand>: invalid choice: 'user-show'
# Oh.. right, it's user-get
keystone user-get <user>
# With openstackclient:
openstack user show <user>

Hey, this is already better. Openstackclient does more than wrap around the clients to unify and standardize the interfaces, though: it also improves the user experience.

Impoving and streamlining the user experience

I thought Openstackclient merely did a one-to-one mapping of current client commands to Openstackclient commands but I couldn’t have been more wrong. They standardize, unify the commands and parameters but they also do things like merge redundant commands into existing ones.

I learned this first hand when I took a stab at implementing a feature Openstackclient did not have yet: Cinder QoS management.

In the context of the Cinder QoS implementation, QoS specifications have fields like:

id
name
consumer
specs (like IOPS limitations)

QoS specifications are also tied to Cinder volume types, these are called ‘associations’. If you don’t know about how Cinder QoS works, there was a great talk about it at the last Openstack summit.

With cinderclient, if you do a cinder qos-list or a cinder qos-show <qos>, you will not see these associations. Instead, you have a command cinder qos-get-association <qos> to see which volume types are associated to a QoS specification.

So, what I ended up doing in Openstackclient is to show the associations in the commands openstack volume qos list and openstack volume qos show. This improved the commands to show more information and “get-qos-association” became redundant so I removed it.

This is just one of the many examples of improvements you might come across in Openstackclient.

Shout out to the Openstackclient core reviewers Steve Martinelli and Terry Howe for giving me great feedback to get QoS support merged. I also appreciated that they were rigorous about the implementation and standards.

Search by name or ID

Another thing I learned is that, where possible, Openstackclient provides the possibility of doing actions on an item either by name or by ID.

You can tell if the commands support them with a ‘help’ on the command:

openstack help volume type delete
usage: openstack volume type delete [-h] <volume-type>

Delete volume type

positional arguments:
  <volume-type>  Volume type to delete (name or ID) <-------

optional arguments:
    -h, --help     show this help message and exit

Predictible, customizable and parsable output

Pretty tables are great in most cases but if you want to do other things.. Like parse them for automation, for example, you’re going to have a bad time.

For some commands, like list, Openstackclient will provide great standard output formatters:

output formatters:
  output formatter options

  -f {csv,html,json,table,value,yaml}, --format {csv,html,json,table,value,yaml}
                        the output format, defaults to table
  -c COLUMN, --column COLUMN
                        specify the column(s) to include, can be repeated

table formatter:
  --max-width <integer>
                        Maximum display width, 0 to disable

CSV Formatter:
  --quote {all,minimal,none,nonnumeric}
                          when to include quotes, defaults to nonnumeric