Vagrant Up Razor-Server

If you want to play with the new razor-server version but don’t feel like installing all the bits by hand, try out a little vagrant script I wrote at So far, it has been tested with the WMware Fusion, and is somewhat of a work in progress. Keep in mind, that it takes a very long time to set it up, as it downloads, installs and configures the following bits:

razor microkernel
ubuntu server image

Once the vagrant is up and running, you will have a fully functional razor-server, setup with a policy and ready to install ubuntu server to the VMs attached to the newly created private network. The base policy will look for VMs with 1 processor.

The Vagrantfile comes with some IPs baked in. If you do not like the IPs I have picked, change them. Please take care that the IPs are in appropriate ranges.

config.vm.provision "shell", path: "", :args =>""

First IP, or $IP_ADDRESS will be the IP of razor-server on the private network created. Note that it will be on eth1.

Second IP, or $IP_RANGE is going to be passed into dnsmasq configuration file for the DHCP range upper limit. The lower limit is the $IP_ADDRESS.

The third IP, or the $IP_BROADCAST is the IP used for broadcast in the ntp.conf. In this case, we have our own ntp server because in some cases you may really need accurate time.

So, check out the code. Then, add a vagrant box:

vagrant box add precise_fusion

Once that is done, you are ready to do vagrant up:

vagrant up --provider=vmware_fusion

Now, go and have some coffee while vagrant does all the work for you!

Once vagrant is done with all the hard work, you can do

vagrant ssh
sudo su -

and use razor commands. They will be a bit slow since razor client is using JRuby instead of a proper version of ruby (the author was cutting corners).

To install a new VM in VMware Fusion, create a new custom VM, add a new network device and specify the newly created vmnet (look for the latest vmnet2 or vmnet3). If all went well, your new VM will do a pxe boot off of a razor, and you will have a new node with Ubuntu server installed.

Happy vagranting and razoring!


Razor-Server Chef Broker

Since razor has been re-written to razor-server, I had to re-write Chef broker as well. I modeled (copied) the new Chef broker after the original one as much as I could. There were, however, some natural differences and some new challenges. The biggest issue was that since the broker configuration JSON is stored as one string in the database, I needed to pass the validation file as one line and re-create valid file format on the broker hand off.

What Does It Do

The Chef broker is run after the post-install part of the razoring process. Once post-install is complete, the broker installation is invoked. The install.erb file for the appropriate broker is called, which contains some bash scripting to install all the needed bits. Chef broker installs chef-client on the new node, creates /etc/chef/validation.pem, /etc/chef/client.rb, and /etc/chef/first-boot.json files. In the end, the content of the first-boot file (contains run list) is executed by calling the following command:

chef-client -j /etc/chef/first-boot.json -E <%= broker.environment %>

The new Chef broker still expects the same inputs as the original broker. Let’s take a look at a sample json file for Chef broker (the new razor really likes JSON. JSON all the things!).

    "name": "openstack_chef_broker",
    "configuration": {
        "install_sh": "",
        "version_string": "11.4.4",
        "chef_server_url": "",
        "validation_client_name": "chef-validator",
        "run_list": "role[allinone]",
        "environment": "openstack",
        "chef_client": "chef-client",
        "validation_key": "MIIok0h+mSHr1Pbi+v2950H1/7mzd71hXAcRHbmrdytAR+RjgtyibkkZTdSxjLP6o2qEuji0I7DL8cckHG56AvuAKhYoadu+9J/2ahmYr18CSqOmg4Sbh6CPm5edpqaAVTbE3Ec+1wN0IMl8KWtmGCrjpXzH1MDdaLZpIIYqC9DUVgLbd/i61hbiiYlky5wPdIKlKwilRl7alfsGKTUrVq1DuYiIZsDYrnYoLOERbzZU6yUxWSIasfVPJGpT9LvstChFjyjv/73etmhXwwIDAQABAoIBAHH1p1upllVJNMSAhSmLZfTe6Q9nT8unRFH1egcsni8dPXYyVzDQ1ztV3RFNDLjP01ZThqkjoA4TnkHvRnC90yR049eQNxn+7pctcTNW61aAglomMhBcFt7LlcDiiXfD3dVhoIDv4ijpfsNCDvEVain9Dv+krjGVP+dWKLKr2azZbrAnyJKJjKb8DkwFET7UADFgUiCwJCW7RyAAxL40WE1hyYGq03cum5+M+2MGTcCiiAumqIRjYyTioNl73zf/ckBKRBNb6DkVGa1drAwXqMtA0MAaJlQBoJJF9SehSf7rAKVMvQ+esS9kNXZhECgYEA28FKbU3K4mU2khZ8lJgomfelWV48sjeIH3OEuLK7WdKg2LAnNajiLAOHYi0egKiMJPnNyZ8uvOY0JABLHQXv10QKaNlHGqy+aRiRSb1Ya6SlbCg8hMoT29yWGa8k7AclLJSn20/dg0GAEQtegi/k3EEZq0CgYEA148QtVh4ng80d9P81rJEDkraAkKUNJPHBSKFqo1rNwSDsyxxTEXIzZSPYS1mjsdB4IxraiNm3WDhb+EldcSlXvmBDjYJck1WyLCw1JuyAS2VCEtdc38aPWGYZ157decuzkR8CU2TKw48KGSRTtwL8yYqTknqpAmnqf/KkWfVNi8CgYEA1a0AnX+Cwtf/U9UhlarN78fosxj6k5+DcHF2n9DKcvBnDctalMZ+BKX5wfB1NEyu2FU9T8rEO1DragYPA01+hCXYqVJ73OgSzUXiH31IuIID9u/0LyseTWOWoIxWJzdTh44xJ+wJlwNuYXxgjgVGaVZk2niXWTLxtTNEdCz0RpECgYAlholhGIq+8WSv656bfaMtXciAFjkYwhUmhrEAVOgyRr3qpjT/EzL23wLq5u1ws617OtbEPm984I2+XVKZIuerFgJqh+uzE1WlUGUoTgZ6AAZu0DfvkFPwFZpjfGY/y0QxsmhpcjDJkQvV+FP3h4UpCh7ZTDLl5axjgt0v3QSYDwKBgFde/5TO8N8U6lHr1YX+yY8wbQ9sVWPU8qruL5Qx11an1tm9Ja1Wbg8Sn0/A7h7Y331V4cDmVraUreULiTQwSO7N26IxQ3Rg/MQG3szUgP0MWYmjuG0c8zaFB73rnBpZ8xakF/xcRTt2Pb62dkw1VqFhzNc50bN+QvGmtEosIB9z"

    "broker-type": "chef"

As you can see, the validation file is on one line, as there is no good way to store formatted files in the database, and creating valid JSON with valid new line characters is also not easy. The whole “configuration” block actually gets flattened to a single line in the database, and as such, parsing must occur at some point. I chose the path of least resistance, one that does not require user to create a valid json from the validation file, rather just strip out new line characters.

Let’s take a look at each line in the configuration file:

"name": "openstack_chef_broker"

Is a name of the broker to be used, and it can be pretty much what you like.

"configuration": {

Is the beginning of configuration for the Chef itself.

"install_sh": "",

This is the omnibus installer to be used for installing Chef on your newly installed server. If you have a closed network or have your own installer, it is likely that you will have a custom installer.

"version_string": "11.4.4"

Chef version to be installed.

"chef_server_url": "",

This is the URL of YOUR Chef server.

"validation_client_name": "chef-validator",

Client name to be used in node’s communication with the Chef server.

"run_list": "role[allinone]",

Initial run list. This is what is going to run after the chef client is installed on the new node.

"environment": "openstack",

Chef environment to be used in the initial Chef run on the new node.

"chef_client": "chef-client",

Binary name for the Chef client installed on the new node. If custom installer installed chef client in a special place or with a special name, specify that here (example: /usr/local/bin/chef-client)


The validation.pem file. This file must be turned into a single line, and the broker will construct it into it’s original form. Let me know if you have ideas on how to do this better.

"broker-type": "chef"

If you want a Chef broker, you must specify “chef” here. This is to tell razor-server that that’s the broker to use after the node install.


First, create broker.json file to contain the json:

    "name": "openstack_chef_broker",
    "configuration": {
        "install_sh": "",
        "version_string": "11.4.4",
        "chef_server_url": "",
        "validation_client_name": "chef-validator",
        "run_list": "role[allinone]",
        "environment": "openstack",
        "chef_client": "chef-client",
        "validation_key": "MIIok0h+mSHr1Pbi+v2950H1/7mzd71hXAcRHbmrdytAR+RjgtyibkkZTdSxjLP6o2qEuji0I7DL8cckHG56AvuAKhYoadu+9J/2ahmYr18CSqOmg4Sbh6CPm5edpqaAVTbE3Ec+1wN0IMl8KWtmGCrjpXzH1MDdaLZpIIYqC9DUVgLbd/i61hbiiYlky5wPdIKlKwilRl7alfsGKTUrVq1DuYiIZsDYrnYoLOERbzZU6yUxWSIasfVPJGpT9LvstChFjyjv/73etmhXwwIDAQABAoIBAHH1p1upllVJNMSAhSmLZfTe6Q9nT8unRFH1egcsni8dPXYyVzDQ1ztV3RFNDLjP01ZThqkjoA4TnkHvRnC90yR049eQNxn+7pctcTNW61aAglomMhBcFt7LlcDiiXfD3dVhoIDv4ijpfsNCDvEVain9Dv+krjGVP+dWKLKr2azZbrAnyJKJjKb8DkwFET7UADFgUiCwJCW7RyAAxL40WE1hyYGq03cum5+M+2MGTcCiiAumqIRjYyTioNl73zf/ckBKRBNb6DkVGa1drAwXqMtA0MAaJlQBoJJF9SehSf7rAKVMvQ+esS9kNXZhECgYEA28FKbU3K4mU2khZ8lJgomfelWV48sjeIH3OEuLK7WdKg2LAnNajiLAOHYi0egKiMJPnNyZ8uvOY0JABLHQXv10QKaNlHGqy+aRiRSb1Ya6SlbCg8hMoT29yWGa8k7AclLJSn20/dg0GAEQtegi/k3EEZq0CgYEA148QtVh4ng80d9P81rJEDkraAkKUNJPHBSKFqo1rNwSDsyxxTEXIzZSPYS1mjsdB4IxraiNm3WDhb+EldcSlXvmBDjYJck1WyLCw1JuyAS2VCEtdc38aPWGYZ157decuzkR8CU2TKw48KGSRTtwL8yYqTknqpAmnqf/KkWfVNi8CgYEA1a0AnX+Cwtf/U9UhlarN78fosxj6k5+DcHF2n9DKcvBnDctalMZ+BKX5wfB1NEyu2FU9T8rEO1DragYPA01+hCXYqVJ73OgSzUXiH31IuIID9u/0LyseTWOWoIxWJzdTh44xJ+wJlwNuYXxgjgVGaVZk2niXWTLxtTNEdCz0RpECgYAlholhGIq+8WSv656bfaMtXciAFjkYwhUmhrEAVOgyRr3qpjT/EzL23wLq5u1ws617OtbEPm984I2+XVKZIuerFgJqh+uzE1WlUGUoTgZ6AAZu0DfvkFPwFZpjfGY/y0QxsmhpcjDJkQvV+FP3h4UpCh7ZTDLl5axjgt0v3QSYDwKBgFde/5TO8N8U6lHr1YX+yY8wbQ9sVWPU8qruL5Qx11an1tm9Ja1Wbg8Sn0/A7h7Y331V4cDmVraUreULiTQwSO7N26IxQ3Rg/MQG3szUgP0MWYmjuG0c8zaFB73rnBpZ8xakF/xcRTt2Pb62dkw1VqFhzNc50bN+QvGmtEosIB9z"

    "broker-type": "chef"

Create broker on the command line:

razor create-broker --json broker.json

Then, create the policy.json file:

  "name": "ubuntu_one",
  "repo": { "name": "ubuntu_server" },
  "task": { "name": "ubuntu" },
  "broker": { "name": "openstack_chef_broker" },
  "enabled": true,
  "hostname": "host${id}",
  "root_password": "secret",
  "max_count": "20",
  "rule_number": "107",
  "tags": [{ "name": "ubuntu_small", "rule": ["=", ["num", ["fact", "processorcount"]], 1]}]

Create policy:

razor create-policy --json policy.json

Now, your policy is set to use the new Chef broker.
Happy installing!


New razor-server vs old razor and what does the rewrite mean to you

If you have not been following google groups and other discussions, this is a summary of the main differences between the original razor and razor-server. The new razor-server is a somewhat different beast than the original razor. If you go to the original git repo,, you will find a note stating “TL;DR: Razor is being rewritten.”

I will not go into the politics of why razor is being rewritten, the google groups provide the official explanation here:!topic/puppet-razor/q4uCVMmUop0

The main differences are in installation and usage, most things are different, and the new razor-server pretty much carried the name only.


When it comes to the technologies used, the new razor-server has gotten rid of node.js components and MongoDB. It is now based on JRuby, and, as the name describes, is a server. The server component is TorqueBox, which in turn is based on JBoss. I have not tried it, but I think this will allow razor-server to be more scalable in the future in terms of deployment size. Database used is PostgreSQL, and the different modes now allow for dev/test/prod instances to run on one server.


Razor-server still uses a microkernel, however, the new MK is based on Fedora rather than Tiny Core Linux. Naturally, this makes the new MK much larger.

State Machine

One of the main things in the original razor was the state machine, which would let you know what state your nodes were in at any given time. At the time of writing, there is no easy way to accomplish the same in the razor-server, but there have been discussions about it, so who knows what will happen in the future.


Original server would collect facts about hardware using lshw. Razor-server does not utilize lshw, and the list of facts at the moment is rather limited. If you need special info about the hardware, you may need additional patches written for the razor-server.


The original razor ran on command line and as a razor service. Razor-server, on the other hand, runs in a JVM based application server, and all interactions with it are based through it is API. There is no need to curl all commands by hand however, since there is also a razor-client available. Razor-client is a command line tool to interact with the razor-server. The one annoyance with razor-client I have that it is super slow if it is using jruby. This means that you have to manage multiple ruby versions and take care that the client is not using jruby while the razor-server is.

In my opinion, razor-server is a little easier to use when it comes to configuring installers (also known as recipes or tasks) and policies, since everything can be passed as a json file instead of multiple commands on the command line.


Razor-server kept the concept of brokers, and currently supports puppet and chef brokers. No broker is still an option. Anybody can also add their own custom broker, however, there is a slight difficulty. Everything in the broker configuration will have to be stored as one entry in the PostgreSQL database. This is a problem if you need to have formatted files transmitted via the broker to the installed server. I had to solve this issue while writing the new Chef broker.


There is no path of upgrade between the versions of Razor and it is very unlikely that there will be one. These are essentially two different tools, both have great parts and the parts that are so-so.



Razor Chef Broker and CentOS

If you are trying to use razor to install CentOS and are running issues with the chef broker hand off, it is likely that this failure is cause the clock difference between your chef client and chef server. To verify, after install of OS is complete, log into your new node and run chef-client.

[root@centos9 ~]# chef-client
 Starting Chef Client, version 11.4.4
 [2013-08-23T07:42:02-06:00] INFO: *** Chef 11.4.4 ***
 [2013-08-23T07:42:02-06:00] INFO: [inet6] no default interface, picking the first ipaddress
 Creating a new client identity for using the validator key.
 [2013-08-23T07:42:03-06:00] INFO: Client key /etc/chef/client.pem is not present - registering
 Chef encountered an error attempting to create the client ""
Authentication Error:
 Failed to authenticate to the chef server (http 401).
 The request failed because your clock has drifted by more than 15 minutes.
 Syncing your clock to an NTP Time source should resolve the issue.

Once the server is installed, fixing this issue is simple. Log in to the server, install ntpdate, and correct the date:

yum install ntp

running chef-client again will be succesful.

However, this is not good enough for automated installs, it would be great if Razor did this to begin with. To correct it, edit file

Before adding puppetlabs repo, add these two lines:

yum -y install

This should be in a patch on github, but it appears that no recent patches have been accepted to the current razor code.


Getting Started Using Razor and Chef (Razor Appliance)

Instead of having everyone to install Razor to demo it during the OpenStack Summit in Portland, I created a Razor appliance. Installing and configuring Razor is not difficult, but could be a little time consuming if you do not have either Puppet or Chef already set up and configured. You can, of course, install it manually or go the Vagrant route:

Slides for the OpenStack Summit tutorial can be found here: (thanks @mattray)

Razor VM

For creating Razor VM, I used Ubuntu 12.04 server. It has the following installed and configured:

Razor (installed using chef:
TFTP server
DHCP server
Chef server (loaded with Rackspace Private Cloud cookbooks
MicroKernel and Ubuntu server ISO loaded

The VM needs to have 2 nics, one for internal, and one for external traffic.

Download VM from here (3.6 GB download): and un-tar it.

Load it either into VMware Fusion or VirtualBox. Please see bellow for special instructions for either!

Login, and switch to root:
username: anystacker
password: razor

Verify Razor is running:

  • root@razor:~# /opt/razor/bin/razor_daemon.rb status

If it is not running, start it up:

  • root@razor:~# /opt/razor/bin/razor_daemon.rb start

Now you can start using Razor. Here are some useful commands:

  • razor image
  • razor node
  • razor active_model
  • razor model
  • razor broker
  • razor policy

Running Razor is not very interesting, unless you try to create a new VM and watch Razor boot it. For this to happen, you will need to create a new VM in either Fusion or VirtualBox. The new VM needs to have a nic on internal network in order to be booted by razor. There are a couple special considerations, depending whether you are using VirtualBox or VMware Fusion.

VMware Fusion

While importing the appliance into Fusion, you may be presented with some errors/warnings. Dismiss them, it should work anyways.

If you are using Fusion, under Preferences/Network, make sure DHCP is disabled for the private network:


Razor appliance will need two nics, public and private. Make sure nic #1 is public:


Razor appliance nic #2 should be set to be on private network. Any subsequent VM to be booted by Razor should also be on private network:


Virtual Box

If you are using Virtual Box:

Make sure the extension pack is installed. To verify it, on command line type the following:

  • VBoxManage list extpacks

If you do not have extention pack, get it here:

When importing Razor appliance, accept all default settings, do not change anything. When creating a new VM to be booted by Razor, change boot order and set network to be internal.

For changing the boot order to include network boot, after creating a new VM, go to it’s Settings and under System, and select network boot order.


Once the boot order is set, change the VM network to be attached to internal network. It should look similar to this:


Now, once the new VM is powered on, it should start booting. If you are presented with an option to select a start up disk, cancel out of it. If Razor is listening on the right network, and your VM settings are correct, you should see something like this:


It should be followed by Razor Mikro Kernel loading information and then regular installation.


I did not try this myself, but @VMRandy was able to import the appliance into vSphere. First he uploaded it to Workstation, upgraded to hardware version 9, and then uploaded to vSphere. Once the VM was loaded and network configured, he was able to boot new nodes in vSphere using Razor.

If Things Don’t Work

Most likely, it is the network.

  • Check the settings, make sure Razor appliance has two nics, a public and a private.
  • Make sure there are no other DHCP servers affecting things and confusing your new VM.
  • Make sure the new VM is connecting on Private Network.
  • Make sure Razor appliance eth1 is listening on
  • Make sure Razor is running.
  • Make sure MongoDB is running.
  • If using Virtual Box, install extension pack.
  • If using Virtual Box, set boot order.

There are a few other things that could go wrong, but usually, it’s the network.

Everything Is Working, Now What?

Congratulations, you were able to download a large file from the internets, successfully imported into your favorite virtualization software, and deployed your first VM using Razor. If you list the Razor policies setup, you will notice that there are two of them. The second policy is for servers with two nics, and will install OpenStack for you on such servers. Go ahead and try- when creating a new server, make sure both nics are on private network. This time, spinning up a new server will take a little longer, as the Razor hands off the new node to the broker. The broker, in turn, will install chef client on it and run the initial run list. In our case, it is OpenStack installation.

Don’t stop at two servers! Try adding different policies and tags, and create servers with different configurations to match them. Check the “razor active_model” command, and see how it matches up with the “knife node list” command.

Have fun!


P.S.: about the making of USB sticks:

P.S.S.: youtube video of the OpenStack Summit presentation:


Razor Broker Custom Metadata

Ever wanted to know what information Razor collects about your system that you could lay your hands on? Wonder no more!

When handing of your newly created node to a broker, besides installing the client and registering it with the server, Razor also injects custom facts into the new node. They consist of two parts, “razor_metadata” and “razor_attributes”. Razor metadata is available for both chef and puppet brokers, and consist of the following:

razor_metadata: {
    razor_tags: "memsize_1GiB,nics_1,cpus_1,IntelCorporation,vmware_vm",
    razor_node_uuid: "JtFXS98553aTEsrUhy6V9",
    razor_active_model_uuid: "PQG5iXxTIDGgEeIQ9qsnD",
    razor_model_uuid: "7RdhL19S5pBAAWTqNldfSl",
    razor_model_name: "ubuntu_precise",
    razor_model_description: "Ubuntu Precise Model",
    razor_model_template: "linux_deploy",
    razor_policy_count: "14"

Razor attributes are a bit more extensive, and I believe are currently injected only into the chef broker. This very detailed information about your system is collected by the Razor microkernel, and can also be found under active model/node/@attributes_hash in the database. The data looks like this:

razor_attributes: {
    mk_hw_cpu0_size: "2200MHz",
    mk_hw_lscpu_CPU_MHz: "2199.513",
    mk_hw_mem_description: "System Memory",
    mk_hw_nic0_clock: "66MHz",
    mk_hw_cpu0_physical_id: "4",
    ipaddress_lo: "",
    mk_hw_fw_physical_id: "0",
    processorcount: "1",
    macaddress: "6A:8C:81:E3:6C:75",
    mk_hw_nic0_version: "01",
    mk_hw_disk0_size: "20GiB (21GB)",
    manufacturer: "VMware, Inc.",
    mk_hw_bus_version: "None",
    architecture: "i386",
    memorytotal: "1005.62 MB",
    mk_hw_nic_count: "1",
    mk_hw_disk_count: "1",
    mk_hw_lscpu_L2_cache: "256K",
    mk_hw_lscpu_CPU_sockets: "1",
    mk_hw_cpu0_slot: "CPU socket #0",
    network_lo: "",
    hardwareisa: "unknown",
    mk_hw_lscpu_Stepping: "7",
    mk_hw_fw_capabilities: "isa pci pcmcia pnp apm upgrade shadowing escd cdboot bootselect edd int5printscreen int9keyboard int14serial int17printer int10video acpi smartbattery biosbootspecification netboot",
    "mk_hw_lscpu_CPU_op-modes": "32-bit, 64-bit",
    mk_hw_nic0_width: "64 bits",
    mk_hw_cpu0_vendor: "Intel Corp.",
    processor0: "Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz",
    mk_hw_lscpu_Byte_Order: "Little Endian",
    netmask_eth0: "",
    mk_hw_fw_vendor: "Phoenix Technologies LTD",
    mk_hw_nic0_logical_name: "eth0",
    mk_hw_disk0_logical_name: "/dev/sda",
    domain: "dns.hosts",
    macaddress_dummy0: "6A:8C:81:E3:6C:75",
    boardserialnumber: "None",
    mk_hw_bus_vendor: "Intel Corporation",
    mk_hw_cpu0_capabilities: "boot fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss nx rdtscp x86-64 constant_tsc up arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm ida arat epb xsaveopt pln pts",
    mk_hw_mem_size: "1GiB",
    mk_hw_lscpu_L1i_cache: "32K",
    mk_hw_cpu0_serial: "0008-06A9-0187-0000-0000-0000",
    mk_hw_fw_size: "87KiB",
    network_eth0: "",
    hostname: "mk000C291F2C5C",
    mk_hw_lscpu_Model: "42",
    netmask_lo: "",
    mk_hw_nic0_capacity: "1Gbit/s",
    mk_hw_cpu0_product: "Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz",
    mk_hw_fw_description: "BIOS",
    ipaddress: "",
    physicalprocessorcount: 1,
    macaddress_eth0: "00:0B:29:1F:2D:5C",
    mk_hw_nic0_bus_info: "pci@0000:02:01.0",
    mk_hw_disk0_bus_info: "scsi@2:0.0.0",
    boardproductname: "440BX Desktop Reference Platform",
    mk_hw_bus_product: "440BX Desktop Reference Platform",
    mk_hw_cpu0_width: "64 bits",
    mk_hw_mem_slot: "System board or motherboard",
    mk_hw_lscpu_L1d_cache: "32K",
    mk_hw_nic0_configuration: "autonegotiation=on broadcast=yes driver=e1000 driverversion=7.3.21-k8-NAPI duplex=full firmware=N/A ip= latency=0 link=yes mingnt=255 multicast=yes port=twisted pair speed=1Gbit/s",
    mk_hw_cpu0_version: "6.10.7",
    mk_hw_fw_date: "07/02/2012",
    fqdn: "mk000C291F2C5C.dns.hosts",
    mk_hw_lscpu_CPU_family: "6",
    virtual: "vmware",
    mk_hw_nic0_size: "1Gbit/s",
    mk_hw_cpu0_description: "CPU",
    serialnumber: "VMware-56 4c e7 4d ae 3c 03 d5-4f e6 9e dc a4 1f 3c 6c",
    mk_hw_bus_physical_id: "0",
    hardwaremodel: "i686",
    mk_hw_lscpu_Architecture: "i686",
    mk_hw_nic0_physical_id: "1",
    boardmanufacturer: "Intel Corporation",
    mk_hw_bus_description: "Motherboard",
    mk_hw_disk0_physical_id: "0.0.0",
    mk_hw_cpu0_capacity: "4230MHz",
    mk_hw_lscpu_BogoMIPS: "4400.31",
    mk_hw_mem_physical_id: "e2",
    type: "Other",
    mk_hw_nic0_capabilities: "pm pcix bus_master cap_list rom ethernet physical logical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation",
    mk_hw_cpu0_bus_info: "cpu@0",
    is_virtual: "true",
    mk_hw_fw_version: "6.00",
    netmask: "",
    mk_hw_lscpu_Vendor_ID: "GenuineIntel",
    mk_hw_nic0_serial: "00:0c:27:2f:1c:7c",
    mk_hw_cpu_count: "1",
    ipaddress_eth0: "",
    productname: "VMware Virtual Platform",
    mk_hw_bus_serial: "None",
    mk_hw_nic0_description: "Ethernet interface",
    interfaces: "dummy0,eth0,lo",
    mk_hw_lscpu_L3_cache: "6144K",
    memorysize: "1005.62 MB",
    mk_hw_disk0_description: "SCSI Disk"

Once this data is injected into the chef node, you can access it just like any other attribute.


Razor Chef Broker, Updated

If you are looking for info on the razor-server broker, check this blog post:

A few weeks ago i posted about the razor chef broker, while it was still a work in progress.  After some awesome collaboration with Fletcher Nichol, Tom McSweeney, and Cody Bunch, chef broker is now officially part of Razor.

Originally, while puppet broker was the only one available, the CLI options for adding a broker were geared towards it.  While working on chef razor, many more options were needed, so the whole CLI interaction for adding a broker changed. The new flow flows much nicer, in my opinion!

Here is a simple example of adding new razor broker, step by step.
Lets check available plugins, make sure that the chef is one of the available options:

root@ubuntu:/opt/razor# razor broker get plugins

Available Broker Plugins:
 Plugin Description
 puppet PuppetLabs PuppetMaster
 chef Opscode Chef

List current brokers:

root@ubuntu:/opt/razor# razor broker
 Broker Targets:
 Name Description Plugin UUID
 puppet puppet puppet 11fTD6ejTXmbS4nyIu0ZF5

Lets add a new broker (-p for plugin, -n for name, -d for description):

root@ubuntu:/opt/razor# razor broker add -p chef -n Chef -d Production
 --- Building Broker (chef):
Please enter the URL for the Chef server. (example:
 (QUIT to cancel)

Your chef server can be in any valid URL format, whether it be IP:port, or just IP. This is were your new client will be connecting to to call home.


What chef version do you want to use?

Please enter the Chef version (used in gem install). (example: 10.16.2)
(QUIT to cancel)
> 10.16.2

Chef client needs a server validation file. This generally can be found on your server under /etc/chef/validation.pem. Copy the whole file, paste, and add a blank line:

Please enter a paste of the contents of the validation.pem file, followed by a blank line. (example: -----BEGIN RSA PRIVATE KEY-----\nMIIEpAIBAA...) 
(QUIT to cancel)

How should your client auth against chef server? More info on chef auth can be found here:

Please enter the validation client name. (example: myorg-validator) 
default: chef-validator
(QUIT to cancel)
 > chef-validator

Which environment? More about Chef environments:

Please enter the Chef environment in which the chef-client will run. (example: production) 
default: _default
(QUIT to cancel)

This script will actually perform the installation. Replace with your own if you don’t trust the internets!

Please enter the Omnibus installer script URL. (example: 
(QUIT to cancel)

More custom options, press enter for default:

Please enter an alternate path to the chef-client binary. (example: /usr/local/bin/chef-client) 
default: chef-client
(QUIT to cancel)

Optional run list, type “SKIP” if you don’t have any.

Please enter an optional run_list of common base roles. (example: role[base],role[another]) 
(SKIP to skip, QUIT to cancel)

Finally, you have a brand new chef broker, ready to be added to your policy:

 Name =>  Chef
 Description =>  Production
 Plugin =>  chef
 UUID =>  7HYCfiyr5LQ13ScnLoRlUB
 Chef Server URL =>
 Chef Version =>  10.16.2
 Validation Key MD5 Hash =>  6372aca0ebceddb65c4e934d35f789c2
 Validation Client Name =>  chef-validator
 Bootstrap Environment =>  _default
 Install Sh Url =>
 Chef Client Path =>  chef-client
 Base Run List =>

Now, when listing available brokers, you should see your new chef broker in the list:

root@ubuntu:/opt/razor# razor broker
Broker Targets:
 Name   Description  Plugin           UUID           
Chef    Production   chef    7HYCfiyr5LQ13ScnLoRlUB  
puppet  puppet       puppet  11fTD6ejTXmbS4nyIu0ZF5

You can view the details of the broker by specifying it’s UUID:

root@ubuntu:/opt/razor# razor broker 7HYCfiyr5LQ13ScnLoRlUB
 Name =>  Chef
 Description =>  Production
 Plugin =>  chef
 UUID =>  7HYCfiyr5LQ13ScnLoRlUB
 Chef Server URL =>
 Chef Version =>  10.16.2
 Validation Key MD5 Hash =>  6372aca0ebceddb65c4e934d35f789c2
 Validation Client Name =>  chef-validator
 Bootstrap Environment =>  _default
 Install Sh Url =>
 Chef Client Path =>  chef-client
 Base Run List =>  

Razor Facts

Besides installing chef client and registering it with the server, Razor also injects custom facts into the new node. I split them out into additional blog post, since there are a few of them!


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:


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