My team at Dell has created many barclamps to support OpenStack and Hadoop. One major objective of our recent modularization refactoring was to make it easier to the community to contribute barclamps. The Crowbar CloudOps approach is to build up a full cloud deployment using layers. So each barclamp represents a component of the overall deployment.
Note 9/21/12: Added Video Post showing the steps below.
Note 9/7/13: Reference to Crowbar Docs.
A barclamp is a deployment module that is imported from its own code repository into the Crowbar framework. A barclamp cannot operate without Crowbar, but you do not have to create a unique build of Crowbar in order to create a barclamp.
The first thing to know about barclamps is that most of the work (80%!) is building your Chef cookbooks. If you don’t have a cookbook that deploys your application then stop here and work on that first.
The second thing to know about barclamps is that there are a lot of them that you can study for examples. Check out the Glance barclamp if you have a single server deployment, Nagios if you have a service that needs to be integrated into every node, Nova if you have a complex multi-component system and Provisioner if you want to impact core Crowbar functionality.
We’ve done a lot of work to make it easy to create and install a stub barclamp. Our experience is that building a barclamp is a highly iterative exercise with a lot of testing. Luckily, Crowbar’s primary mission is to help you brush, rinse and repeat. From there, you can customize and extend your barclamp to deploy your application’s full untamed glory.
Before you try to create a new barclamp, you must install Crowbar.
Creating a barclamp
The following steps use the barclamp_model that included under /dell/opt and is described below.
Figure out the name of your barclamp. I’m naming our example “foo barclamp”
- Barclamps must have unique names.
- Do not use spaces or hyphens.
- From the Crowbar server, become the super admin: sudo -i
- Create a directory for your barclamp: mkdir /barclamps
Run the barclamp create script: /opt/dell/bin/barclamp_create.rb foo “Zehicle” /barclamps
- “foo” is our barclamp name [required]
- “Zehicle” is my company name for the copyright information [default is Dell]
- “/barclamps” is the path where we are putting the barclamp [default is /opt/dell/barclamps]
- Result will be a populated barclamp. In this example: /barclamps/foo
That’s it! If you want to plan ahead then you could use an initialized git repo as the target.
Reminder: In building your barclamp, you’ll need to learn about Chef, how Crowbar extends cookbooks and how barclamps interact. That’s beyond the scope of this post.
Importing a barclamp
Once you created a barclamp, you can import the barclamp into Crowbar & Chef.
Assuming that you already created the foo barclamp in /barclamps, here are the steps:
- From the Crowbar server, become the super admin: sudo –i
Run the barclamp install script: /opt/dell/bin/barclamp_install /barclamps/foo
- “/barclamps/foo” is the path to your barclamp. If could be anything!
- The core barclamps are in /opt/dell/barclamps.
- In a vm, you could mount a shared folder to access the barclamp (e.g.: /mnt/hgfs/barclamps)
Your barclamp should now show up in the Crowbar UI! You can also see it in Chef under the Crowbar databag.
While barclamps are generally safe to install multiple times, you can uninstall a barclamp using “barclamp_uninstall.rb /path/to/barclamp”
A barclamp has the following core components:
- crowbar.yml configuration file (documented below)
- README.txt file (optional, recommended)
chef directory containing
- Cookbooks directory with Chef cookbooks
- Data_bags directory with Crowbar configuration files
- Roles directory with Chef roles used by the cookbooks and data_bags
- app directory with Crowbar model, controller, and view code
- other optional directories to add components needed by the UI such as images
The barclamp_model has a functional layout that covers most configuration requirements. The string ==BC-MODEL== indicates places where the name of the barclamp must be substituted. It is critical to understand that the name of the barclamp is embedded into the barclamp path and file names! This is needed to avoid file collisions when the barclamp is imported.
The crowbar.yml file is a required configuration file that gives direction to the installer. The file has the following components:
barclamp: name: name of your barclamp (required, do not use space or hyphens) display: pretty name of your barclamp [optional for now] description: information about your barclamp your barclamp [optional for now] version: what you want to consider for versioning [optiona] crowbar: layout: 1 (use the # one. This is required because it tells the installer what to expect inside your barclamp) order: 1000 (if installing multiple barclamps in one pass, order tells the installer the, well, order) nav: (remove the nav section, advanced users only) locale_additions: (you must add UI localizations here if you have any custom UI components) en: (entries in this file map directly to entries in the config/locales/en.yml file and are added during install)
Pingback: Video of how-to Create a barclamp (15 mins) « Rob Hirschfeld's Blog
Pingback: Opscode, Dell, and Rackspace Are Making Crowbar Even More Awesome | Opscode.com
Pingback: Hadoop Crowbar released to open source! (plus AN HOUR of videos!) « Rob Hirschfeld's Blog
Please let us know if we can use the above mentioned method for creating barclamps in OpenCrowbar also?
No, OpenCrowbar changes made this very different. It was simplified in many regards. In the new model, barclamps decomposed into roles and workloads. They still exist but mainly for organization inside a workload.
Roles are small units of work that are collected into a barclamp.yml file.
Workloads are git repos that contain barclamps/roles and act as siblings for the core project. They are the way we extend Crowbar.
More info: https://github.com/opencrowbar/core/tree/master/doc
Thank you so much for the reply. Should I follow the same for SUSE crowbar also? (SUSE cloud 4)
No. SUSE still use Crowbar 1.
If you are considering extending CB, I strongly recommend focusing on OpenCB where there is a path to support.