by jmrodri

“synergize” with cobbler

I mentioned several days ago that my “Integrating with Cobbler” talk didn’t make the cut at FUDCon Toronto 2009.

Before you can integrate with Cobbler, you need to know a little about its objects and API. Then I can talk about some of the possible integration methods.

Cobbler has the following object types:

  • distro
    • represents the distribution (at a minimum the kernel and initrd locations)
  • profile
    • represents the kickstart description of what you want a machine to look like
  • system
    • represents the actual system
  • repo
    • package repository for mirroring (optional)
  • image
    • virtual guest image

The API that Cobbler exposes is actually very simple. Most of the objects have a set of operations find, get, remove, copy, etc. The convention used by Cobbler’s api is OPERATION_OBJECTTYPE. For example, to get a distro you would call get_distro(). To find a profile simply call find_profile(). Below is a list of the common api methods exposed by Cobbler. The {object*} represents the object type single or plural.

  • get_{object*(s)}
    • returns the object with the given type and id
  • find_{object*}
    • returns the object with the given criteria
  • get_{object*}_handle
    • returns a reference to be used by modify_* and save_*
  • remove_{object*}
    • removes the object with the given id
  • copy_{object*}
    • copies the object with the given id to the new name
  • rename_{object*}
    • renames the object to the new name
  • new_{object*}
    • creates a new object
  • modify_{object*}
    • changes the value of one of the object’s attributes
  • save_{object*}
    • commit all of the object’s changes

As you can see the API is quite simple and pretty straight forward. I’ve seen many APIs, and Cobbler has one of the cleanest ones I’ve seen in quite a long time.

You like the API as well but don’t use python? We you might consider one of Cobbler’s language bindings:

  • cobbler4j – a Java binding that tries to give you POJOs to work with
  • rubygem-cobbler – a Ruby binding
  • XML-RPC – most languages have an XML-RPC library

Cobbler4j was born from the integration of Spacewalk with Cobbler, primarily because working with XML-RPC from Java SUCKS! Also, most Java guys want to deal with objects, so it was only natural to create a binding for those developers.

Cobbler4j is autogenerated from the Cobbler python code which helps keep it up to date, and avoids the problem of ‘oops I updated the python code but forgot to change cobbler4j’. But what does it look like in practice? Ok, here’s an example of cobbler4j in action:

import java.util.*;
import org.fedorahosted.cobbler.*;
import org.fedorahosted.cobbler.autogen.*;

// REQUIRES: cobbler 2.0
public class Cobbler4jExample {
  public static void main(String[] args) {

    // gets connection and login at the same time
    CobblerConnection conn = new CobblerConnection(
      "http://localhost", "testing", "testing");

    Finder finder = Finder.getInstance();

    // see if there are any distros there already
    List distros = (List) finder.listItems(conn, ObjectType.DISTRO);
    System.out.println("there are " + distros.size() + " distros");

    // create a new distro, name, kernel and initrd are required
    Distro distro = new Distro(conn);
    distro.setName("cobbler-integration-java");
    distro.setKernel("/tmp/cobbler.fake");
    distro.setInitrd("/tmp/cobbler.fake");

    // in order to persist an object, we must call commit method
    distro.commit();

    // see our new distro
    distros = (List) finder.listItems(conn, ObjectType.DISTRO);
    System.out.println("there are now " + distros.size() + " distros");
    for (Distro d : distros) {
        System.out.println(d.toString());
    }

    // cleanup
    distro.remove();
  }
}

That’s cool and all, but I already know how to call APIs exposed by services. But what are some of the strategies for putting Cobbler into my application? I’m glad you asked (if not, you really should be thinking this) 🙂

There are basically 3 ways of setting up Cobbler for your application.

  • Standalone
  • Master
  • Slave

Standalone is just that, you simply run Cobbler as a Service (CaaS) and use it to manage your DHCP, PXE infrastructure and deploying your systems. No other integration besides maybe a few scripts to fit into your processes. This is one of the popular use cases.

Next, we have the Master setup. This means you might have an in house integration GUI or other application but you let Cobbler be the canonical location for the provisioning data. Your application simply passes through to Cobbler’s APIs. The Genome project uses Cobbler in this way.

Lastly, there’s what I call the Slave mode. This setup is when you have an application that does a lot more than what Cobbler was meant to do and have more data than Cobbler is meant to handle. Your application will be the canonical source of the data, and will sync it to Cobbler on a periodic basis. Spacewalk is an example of using the Slave method of integration.

So which is the best way of integrating with Cobbler? Honestly it completely depends on your situation and needs. All of the above strategies are correct. So figure out what your application does best and whether you want to have to do synchronization of data or if you need your own application at all.

Happy integrating! If you want to see my presentation on this topic checkout my Fedora people page: http://jmrodri.fedorapeople.org/cobbler-integration.pdf (PDF)

Leave a comment