OpenLMI vs. Puppet

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.

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.

4 Responses to OpenLMI vs. Puppet

  1. devops says:

    its very similar . I dont understand why we need both technologies
    you can discover all in puppet code .

    here is one of the obvious overlaps :

    firewall-cmd –add-port 5989/tcp


  2. Russ Doty says:

    The difference is that OpenLMI is intended to provide a standardized remote API for querying, monitoring and updating systems – it is designed to interact with a system. Think of it as a library of system management commands.

    Puppet (and Chef and other systems) are designed to put a system into a specified state. Basically, you define what you want the end state to be and Puppet does it.

    Puppet depends on modules, usually scripts, to make changes to a system. There is considerable variation on how these scripts work.

    So, the interaction and use models are quite different. An interesting topic to explore is if the standardized libraries supplied by OpenLMI can be called by Puppet, potentially improving the way Puppet interacts with target systems.

  3. silviu d says:


    Would you classify OpenLMI as orchestration on steroids ?
    Something that could compare with SaltStack for example.


    • Russ Doty says:

      Hmm, good question.
      The OpenLMI Providers basically give you a remote callable library to query and manipulate a server.
      Client side tools, notably LMIShell, can be used to implement orchestration.
      The way I look at it, OpenLMI provides a foundation that can be used for orchestration, but doesn’t actually provide orchestration capabilities itself. What do you think?
      And, of course, exactly what do you mean by orchestration?

Leave a Reply

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

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

Facebook photo

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

Connecting to %s