A common question is “what is the difference between OpenLMI and a configuration management system like Puppet or Chef?” This is often asked with the implication that these are competitive approaches and you don’t need both. The two approaches are quite different, and actually complementary to each other.

OpenLMI is built on a model of interactive query, modify, and notify against a single system. It provides a standardized API for various subsystems, which will grow over time. OpenLMI also supports a variety of client applications and interfaces, including an API plus task focused scripting, CLI, and graphical interfaces.

Puppet, on the other hand, uses a special language to create recipes which put systems into a known configuration. Puppet is also idempotent, meaning that you can run the same configuration multiple times with the same result. With Puppet, you specify the outcome, and Puppet has the responsibility of getting there.

The difference between these approaches can be seen with some examples.

Let’s assume that we are bringing up a new server. This new system has 9 disk drives, 4 NICs, and needs to be set up to use AD for authentication. Using OpenLMI, you can interactively enumerate all the drives on the system (including the one that contains the OS), identify the 8 that are available, partition them, combine them into a RAID 5, format them with XFS, and configure volume groups on them. You can then take the four NICs, configure them with IP, netmask, and dns, bond two of them together for performance, and set up VLANs. You can then add the software for AD support (realmd) and add the system to an AD domain.

Yes, you could perform most of these operations using Puppet. But you would need to know the details of the system configuration and create the appropriate recipe. If you have 10 or 100 identical systems, that would be the way to go. If you have 10 different servers with different configurations it is easier to set them up one at a time.

On the other hand, if you have 100 database servers and you want to protect them by disallowing incoming http traffic, it would make sense to create a Puppet recipe to configure the firewall to block incoming traffic on port 80 on all database servers. If you were using Puppet, you would probably have your entire firewall configuration in a Puppet recipe; you would modify this recipe with the desired changes and allow it to automatically propagate across all targeted systems.

You could also do the firewall changes in OpenLMI by creating a script in lmishell to change the firewall rules and remotely running this OpenLMI script against all the database servers.

It should be possible to combine Puppet and OpenLMI. The core of OpenLMI is a set of agents which operate on the managed systems and present a standard interface. Puppet requires agents on the managed systems to make changes. We aren’t aware of anything that would prevent you from writing Puppet agents which call the OpenLMI agents to do the actual work; this would give you the best of both worlds.