Skip to content


Subversion checkout URL

You can clone with
Download ZIP

Crowbar 2.0 FAQ

Adam Spiers edited this page · 8 revisions
Clone this wiki locally

Organizational and Technical Background

Why do we need a redesign?

From Crowbar 1.x

While Crowbar 1.x functions, its codebase is unsustainable. It needs to be re-written.

Crowbar depends upon a variety of products - Chef foremost among them. The Crowbar team wants to take advantage of the significant advances of these products, but also give the user freedom to choose replacements. This gives us the opportunity to also re-design crowbar's core, based upon what we've learned over the last two years, and the evolving strengths of the products. Crowbar 1.x was specifically designed to work with Chef 10, and ceased to function properly when upgrading to Chef 11.

Crowbar 2.0's vision is significantly expanded from Crowbar 1.x.

  • CMDB agnostic through the Jig system
  • RDBMS backed (instead of Chef's database)

Crowbar 1.x was designed specifically to work with Chef 10. Significant gains are made by upgrading to Chef 11, including removing much code that worked around Chef 10's problems.

Recent re-design

Our first attempts at re-designing Crowbar last year suffered from the following flaws, which we hope to address with the mid-2013 redesign:

  • Overly complex data model in Crowbar Core.
  • Jobs system was over engineered and didn't respond to direct solution needs
  • CMDB/Jig system was over-designed, and too tightly controlled the client
  • There was no clear orchestration <-> eventual consistency feature (now the Annealer)
  • We want a more open architecture to allow plugins in a variety of places.

What are the big changes?

  • introduction of a database
  • introduction of the jig (see below)
  • model redesign, including a new state machine (the "annealer" - see below)
  • switching to upstream non-Crowbar-specific community cookbooks
  • Chef 11
  • Ruby 1.9
  • Rails 3.2
  • Linux packaging
  • integrated documentation model (based on markdown)
  • consistent API w/ validation

What is the Annealer?

The Annealer is somewhat like a scheduler. It drives the node-roles through their life-cycles on the appropriate Jigs. There is an implied state machine created by the dependencies of node-roles between each other. It drives the implied state machine, reporting on its state at every phase of "annealing."

What is the jig, and why do we need it?

Jigs are abstraction layers between the Crowbar Annealer and any node control product, like Chef, Puppet, scripts, Ansible, etc. They report node-role state back to the Annealer.

There are several advantages to introducing the jig into the design:

  • Enforces Chef cookbooks etc. to be de-coupled from Crowbar with clearly defined integration points, so that upstream cookbooks can be consumed unmodified.
  • De-coupling makes it possible to debug upstream cookbooks in a standalone Crowbar-less environment, e.g. via Chef Solo (for openSUSE, this is supported via soksolok)
  • Introduces the possibility for different backends (Puppet etc.)
  • Allows cleaner bootstrapping via a script jig which installs Crowbar and all other Jigs. It SSHes into the node, copies the appropriate scripts into place, and supplies attribute data through JSON. Since this is still done via the Crowbar Rails app, the orchestration layer can be used to bootstrap via the annealer without requiring any significant "special case" code.

Why do we need a database? (instead of Chef or NoSQL)

We've chosen PostgreSQL as our database. Initially it was a significant performance gain, but we chose not to depend upon Chef-Server to manage our Crowbar specific data. The change offers system architects more choices in how (or if) they run the Chef-Server. It also gives barclamp creators greater flexibility in storing attribute data and delivering it across nodes, roles and even barclamps.

How has the installation process changed?

The Script jig now does the majority of the installation procedures.

Why is it taking so long?

We took some wrong turns both technically and with regards to community engagement. Thanks to our friends at SUSE, we're learning a great deal about producing great open products and interacting well with the community.

Dell is determined to support the open source community, and the process has been incremental. We don't have many folks who are accustomed to Open Source development processes, and it's taken a while for us to get organized. The Crowbar team has gone through a re-organization and some hiring to help improve community interaction.

We welcome your participation! Hopefully this FAQ is a step in the right direction.

Something went wrong with that request. Please try again.