RazorProvision like a bossDavid LutterkortPrincipal Engineer | Puppet Labs @lutterkortlutter@puppetlabs.com

Who are you ?• Joined Puppet Labs in May

• One of the first contributors to Puppet

• Started Augeas

• Apache Deltacloud, DMTF CIMI

• email: lutter@puppetlabs.com

• IRC: lutter, twitter: @lutterkort

Razor history• Started by EMC/VMWare

• Nick Weaver, Tom McSweeney

• EMC World 2012

• PuppetConf 2012

Ingredients• ipxe

• Hardware discovery and inventory

• Tagging and policies

Where is Razor going• Rewrite for different stack

• Simplify deployment

• Simplify maintenance

• Simplify usage

Don’t muck with the good bits

The more it changes ...• Node discovery with MK and facter

• Use ipxe to control boot

• Written in Ruby

• Flexible tag/rule-based policy match

• Simple handoff to Puppet

• Manage large number of nodes

Foundations

Aside: Torquebox rules• Daemons

• Scheduled Jobs

• Messaging

• Clustering

• Integration with Java libraries

• Java management

Components• Razor server

• Razor CLI

• Microkernel agent

• Microkernel image

• Razor UI

Microkernel• Separate MK agent from OS image

• Build on EL

• well-known hardware support

• formal support offerings

• currently ~ 150MB (unoptimized)

• Enable alternative MK builds

Server API• JSON everywhere

• Query objects with RESTful interface

• Update/modify using commands (CQRS)

• all changes happen async

• Authentication [TODO]

CLI

1> razor nodes

2> razor tags mytag

3> razor create-tag --name=any \ --rule ‘[“=”, 1, 1]’

4> razor create-image --name=... \ --image-url=...

5> razor create-policy --json policy.json

Tags

• A named rule

• Rules can have complex logic

[“or”, [“in”, [“fact”, “macaddress”, “de:ad:be:ef:00:01”, “de:ad:be:ef:00:02”]], [“=”, “2”, [“fact”, “processorcount”]]]

Policies# policy.json{ “name”: “fedora-for-any”, “image”: { “name”: “fedora-19” }, “installer”: { “name”: “fedora-base” }, “broker”: { “name”: “puppet” }, “hostname”: “host${id}.example.com”, “root_password”: “secret”, “max_count”: 20, “enabled”: true, “line_number”: 100, “tags”: [{ “name”: “any” }]}

Installers• OS installation inherently linear

• Completely in metadata

• file based or in DB

• Simple node/server API

• evaluate and fetch ERB template

• store a value (e.g., IP address)

• log a message

Installer example---# redhat.yamlos: Red Hat Enterprise Linuxos_version: 6description: Red Hat EL installerboot_sequence: 1: boot_install default: boot_local

Template example

# os_boot.erbhostname <%= node.hostname %>

yum -y install rubygems facter[ $? -eq 0 ] && curl <%= log_url(“ok”) %>\ || curl <%= log_url(“fail”, :error) %>

#!ipxe# boot_install.erb

kernel <%= image_url(“/vmlinuz”) %> \ ks=<%= file_url(“kickstart”) %>

The road forward• Make release soon (~ 2 weeks)

• Add lifecycle management features

• Userdata for nodes

• Node commands

• Generate events

Possible node commands• Boot locally

• Boot into MK

• register

• update facts

• BIOS/firmware update

• Reinstall OS

• Unbind & run through policy table

Event generation• User-controlled actions (commands)

• Possible events

• node discovered

• policy bound

• installer finished

• policy unbound

Demo time

Don’t be a strangerGithub repos (will change)Server: https://github.com/puppetlabs/razor-serverMicrokernel: https://github.com/puppetlabs/razor-el-mkMailing listhttp://groups.google.com/group/puppet-razorIRC: #puppet-razor (freenode)My email: lutter@puppetlabs.com

Thank YouDavid LutterkortPrincipal Engineer | Puppet Labs @lutterkort

Collaborate. Automate. Ship.

Follow us on Twitter @puppetlabs

youtube.com/puppetlabsinc

slideshare.net/puppetlabs

Collaborate. Automate. Ship.