Razor Chef Broker

Update: there is a newer, official version of razor chef broker. Please refer to this post for more details.

Project Razor is a power control, provisioning, and management application designed to deploy both bare-metal and virtual computer resources. It also provides broker plugins to integrate with third party systems. If such broker is provided as part of the policy for deployments, the broker will be used to hand off the newly deployed node to a DevOps system. Up until now, only Puppet broker was available.  However, if you are already using Chef as your chosen DevOps tool, that should not prevent you from trying out Razor!

For the last week or so I been spending my evenings working on a Chef broker for Razor. It still needs a bit of work done, however, right now my broker successfully registers nodes with the Chef server.

Lets take a look at the cli usage for adding Chef broker.  First, determine what brokers are available:

root@ubuntu:/opt/razor/bin# razor broker get plugins
Available Broker Plugins:
 Plugin Description
 puppet PuppetLabs PuppetMaster
 chef OpsCode Chef

Great, chef is one of the options! Try and add one. If not sure what the parameters are, try this:

root@ubuntu:/opt/razor/bin# razor broker add
[Broker] [add_broker] <-Must Provide: [The broker plugin to use.]
Command help:
razor broker add (options...)
-p, --plugin BROKER_PLUGIN The broker plugin to use. 
-n, --name BROKER_NAME The name for the broker target. 
-d, --description DESCRIPTION A description for the broker target. 
-s, --servers SERVER_LIST A comma-separated list of servers for this broker target 
-c, --certificate CERTIFICATE Full path to the Chef server certificate file 
-v, --version VERSION A target broker version (used in gem install) 
-h, --help Display this screen.

The options for adding Chef broker differ only slighly from the ones used for Puppet broker (current documentation for it is here).  The main difference is “-c” option, to add a path to the Chef server certificate.  The certificate usually be found on your server in /etc/chef/validation.pem file.   Make a local copy of this file so that it can be used to register a new node with the server.

Lets go ahead and add a new broker:

root@ubuntu:/opt/razor/bin# razor broker add -p chef -n Chef_2 -d Chef -s -c /opt/razor/bin/validation.pem 
Name => Chef_2
 Description => Chef
 Plugin => chef
 Servers => []
 UUID => 2B0KgW2xCleWreET16WI4p
 Certificate => /opt/razor/bin/validation.pem
 Version => Default

Associate a current policy with the new broker:

root@ubuntu:/opt/razor/bin# razor policy update 4ZtLkicLls6isgee91JCMN
 [Policy] [update_policy] 4ZtLkicLls6isgee91JCMN
 Line Number => 3
 Label => precise
 Enabled => true
 Template => linux_deploy
 Description => Policy for deploying a Linux-based operating system.
 Tags => [memsize_1GiB, vmware_vm]
 Model Label => install_precise
 Broker Target => Chef_2
 Currently Bound => 26
 Maximum Bound => 0
 Bound Counter => 27

Now, any node deployed using this policy, will be handed off to Chef server.  For hand off,  broker follows these steps:

  • installs chef on the node
  • creates basic /etc/chef/client.rb file with client settings
  • creates /etc/chef/validation.pem file
  • installs ohai
  • calls home (registers itself with the server and provides personal details)

In it’s current form, this broker is already pretty useful!  Next, I will try and provide Chef server with Razor’s custom metadata, so that there is feature parity between Puppet and Chef brokers.  If you would like to try it out, checkout the working branch: https://github.com/eglute/Razor/tree/feature/master/chef_broker


Update: there is a newer, official version of razor chef broker. Please refer to this post for more details.

GitHub Tips for Beginners

Q: How often should I checkin code into github?
A: More often is better than less often, if you write a lot of code, do it at least 2-4 times a day.

Q: Should I branch/fork?
A: branching and forking is there to help you better organize your code by feature. If you are working on an open source project, you will need to fork it first so that you have access to checkin code into it. After you forked a project, you may want to create branches for different features that you will be working on. If you are part of one organization where you have access to the repo, you may want to forgo the forking and go straight to branching. This is a decision that each group needs to make.

Q: Can I work from master?
A: Yes you can, but you probably should not! Think of your master branch as a golden copy of your code. Merge to it after you thoroughly tested your new features or bug fixes.

Q: What if command line scares me?
A: Use GUI tools built just for you!  There are lots of them out there, my favorite one is: http://mac.github.com/


While looking up some documentation for git, I came across this awesome cheatsheet:

Try clicking on it!

You may be aware of github documentation, but do visit git docs once in a while as well to get very clear and detail answers to all your git questions:


Tutorial: Adding Existing Project to Github

If you are currently working on a project that you would like to check into github, it may not be very obvious at first. This step by step tutorial assumes that you already setup your github account.  If you have not, follow these instructions first: https://help.github.com/articles/set-up-git. Once your github is setup, create a new repo trough UI: https://github.com/new

In this example, I will use repo “testRepo”, just to keep it simple!

Now, on your command line, go to your existing project. For the sake of this tutorial, the names of existing project and git repo are the same, but they do not have to be.

My current project has 2 files:

egle@ubuntu:~/testRepo$ ls -la
total 16
drwxrwxr-x  2 egle egle 4096 Nov 16 19:41 .
drwxr-xr-x 25 egle egle 4096 Nov 16 19:40 ..
-rw-rw-r--  1 egle egle   14 Nov 16 19:41 file1.txt
-rw-rw-r--  1 egle egle   15 Nov 16 19:41 file2.txt

To turn this directory into a git repository, I need to initialize it:

egle@ubuntu:~/testRepo$ git init
Initialized empty Git repository in /home/egle/testRepo/.git/

This creates a local git repository on your machine. That’s right, you can version files locally without ever needing to connect to github or other git server! Note that currently your new git repo contains no files.

Add all the files to the repository:

egle@ubuntu:~/testRepo$ git add .

Once the files are added, they need to be committed:

egle@ubuntu:~/testRepo$ git commit -m "first commit"
[master (root-commit) b9c1002] first commit
Committer: Egle <egle@ubuntu.(none)>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
git config --global user.name "Your Name"
git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

git commit --amend --reset-author
2 files changed, 2 insertions(+)
create mode 100644 file1.txt
create mode 100644 file2.txt

In this case, I have not setup my git settings, so will need to fix that later. The important part here is that files got committed to the local repo.  However, local repositories are a little hard to share. Lets add a remote repository, named origin, and push files to it:

egle@ubuntu:~/testRepo$ git remote add origin https://github.com/eglute/testRepo.git
egle@ubuntu:~/testRepo$ git push -u origin master
Username for 'https://github.com': eglute
Password for 'https://eglute@github.com': 
To https://github.com/eglute/testRepo.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

Now your current project is in github, ready for pulls, pushes, merges, branches, and forks!



Fun with Git Config

It seems like everyone is using github these days, and it is easy to fork and branch trough it’s UI. But what if you are just starting with using git?

I will reveal a few not so hidden secrets of git. First, github is based on git, so if you just been reading github documentation, you are missing out on a lot of great documentation that can be found here: http://git-scm.com/doc.

Second, when you are using github, you are really working with two repositories, not one. The first one is on your local machine, set up to point to the second, remote repo.

Here are a few tips on how to configure your local repo:

You will want to start with git config tool to configure your git profile. git config will setup your identity and some preferences.

Start with setting your name:

egle@ubuntu:~/testRepo$ git config --global user.name "Any Stacker"
 egle@ubuntu:~/testRepo$ cat ~/.gitconfig
 name = Any Stacker

A few more settings:

egle@ubuntu:~/testRepo$ git config --global merge.tool vimdiff
 egle@ubuntu:~/testRepo$ cat ~/.gitconfig
 name = Any Stacker
 tool = vimdiff
 egle@ubuntu:~/testRepo$ git config --global core.editor vi
 egle@ubuntu:~/testRepo$ git config --list
 user.name=Any Stacker

Don’t be a git, check in your code often!


Book: OpenStack Cloud Computing Cookbook, by Kevin Jackson

If you are following the cloudscape, you may have noticed that OpenStack is getting a lot of attention right now.  If you never even heard of OpenStack, cookbook by Kevin Jackson is not the right place for you to start. For the very green I would suggest http://devstack.org/.

For those that want something a little more advanced, I would recommend picking up a copy OpenStack Cloud Computing Cookbook.  Whether you are building your very own private cloud or maintaining one, this book is right for you.

Recipes start with setting up sand box environment on VirtualBox, followed by Essex install on Ubuntu Precise (12.04).  After basic install, the book covers installing, configuring, and administering all of the components of OpenStack.  Chapters 2 and 3 cover compute and keystone components.  Chapter 4 starts out with a setup of swift (storage component) sand box environment. Chapters 5 and 6 are more Swift recipes. Glance, Nova, Horizon and Networking get the next 4 chapters, while 11 and 12 cover practical details like installing OpenStack on bare metal (MAAS) and monitoring. The last chapter delves into troubleshooting, logging, submitting bug reports, and getting help from community.

What this book is not: an in-depth explanation of OpenStack components. It is also not OpenStack for Dummies.  However, if you just want to get things working, this is a great reference book.