Introducing LMIShell – the OpenLMI Client

Our discussions so far have focused on the OpenLMI agents and infrastructure on managed systems. This makes sense, as the management infrastructure has to be in place before any client applications can use it. The client side has not been ignored – far from it! The OpenLMI developers have been busy building a client application that works the way Linux System Administrators do.

How do Linux SysAdmins work? Mainly through command line and scripts. The scripts may be written from scratch, but most commonly are modifications of existing scripts. There is a huge base of scripts and commands floating around the Internet, and the most common way to solve a problem is to “Google it” and copy commands or scripts.

When you look at the OpenLMI API, you will notice that it is powerful, complex, and low level. It is good for programmers, but not optimal for SysAdmins. And the WBEM interface is CIM-XML over https. You certainly can engage in hand-to-hand combat with XML, but most people don’t want to.

We were also aware that SysAdmins think in task oriented terms like “what drives are on this system?”, “partition drive sda with xfs”, “build a RAID 5 set from drives sdb, sdc, sdd and sde”, and so forth. SysAdmins want a high level, task oriented, extensible interface. Oh, and some consistency and documentation would be nice…

LMIshell has been developed to address these needs.

OpenLMI Architecture featuring LMIShell structure.

OpenLMI Architecture featuring LMIShell structure.

LMIshell is a client application/environment. It runs on a client system (which may also be the same as the managed system). A single LMIshell client can connect to multiple managed systems. Only LMIshell has to be installed on the client system; it is only necessary to install the Object Broker and Agents on managed systems. Likewise, there is no need to install LMIshell on managed systems.

LMIshell is based on Python, and can be used interactively or in a batch mode. Starting at the bottom of the stack, LMIshell handles the task of communicating with the OpenLMI Object Broker. It deals with the https communication and with parsing the CIM/XML. It does this by transforming everything into native Python objects – this means that OpenLMI classes become Python classes, that OpenLMI attributes become Python attributes, and that OpenLMI methods are invoked using Python method calls. This greatly simplifies working with OpenLMI.

The next thing implemented in LMIshell is a set of helper functions. We noticed that there are things that you do over and over when working with OpenLMI. For example, each OpenLMI API call sent across the WBEM communications interface specifies the target system and the username and password to use. This is a nuisance for people, but easy for computers. LMIshell helper functions let you establish a connection object containing this information, which is then used for all subsequent calls in that LMIshell session (until you change it to manage a different system).

The next challenge was to somehow change the low-level standards-based OpenLMI API into something SysAdmins would want to use. When wrestling with this challenge, we noticed that management scripts were commonly used as documentation and templates – SysAdmins would find a script that did something close to what they needed, study how it worked, and modify it. In fact, they would often do this instead of reading documentation.

We also noticed that management scripts were often written quickly to accomplish a specific task. As a result, they are not always well structured, might not have good error handling, would not correctly deal with corner cases, and were not always easy to extend. Further, scripts from different sources would have very different styles and conventions, complicating the task of joining them together.

Keeping these factors in mind, and considering that we were working in a full Python environment, we decided to develop OpenLMI Modules – SysAdmin focused, task oriented, extensible modules that hide the complexity of the low-level OpenLMI API.

These OpenLMI modules have multiple goals – do useful work, provide documentation and examples of how to use the low-level OpenLMI API to do a variety of tasks, provide a starting point for customization and extension, and to bring software engineering best practices to management scripts.

OpenLMI Modules are a great improvement in ease of use for SysAdmins, but they still balance power with complexity. For the greatest ease of use we have also implemented OpenLMI Commands – a high level CLI designed for use from the command line and in shell scripts.

OpenLMI Commands are the easiest to use and are designed for the most common tasks. OpenLMI Modules are designed to address a broad range of management tasks. The OpenLMI API provides a low level programming interface that delivers the full range and power of OpenLMI. Between them you have several ways to perform management tasks, and the ability to “mix and match” as needed.

About Russell Doty

A technology strategist and product manager at Red Hat, working on the next generation of open source systems.
This entry was posted in System Management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s