Skip to content
This repository

This is the initial version of Razor. It's been rewritten and can be found at

branch: master
Octocat-spinner-32 acceptance-spec Merge `SliceUtil::Common` module into the one place it is used April 03, 2013
Octocat-spinner-32 acceptance Update acceptance tests after internal machines were renamed. May 29, 2013
Octocat-spinner-32 bin Use `get_node_instance_info` to target stopping node processes April 16, 2013
Octocat-spinner-32 conf Implement Puppet Labs best-practice version handling November 01, 2012
Octocat-spinner-32 ext (packaging) Remove Ubuntu Oneiric from build targets June 25, 2013
Octocat-spinner-32 image Changing downloads to multipart and the filename to be added to heade… March 29, 2012
Octocat-spinner-32 install Added new README January 24, 2012
Octocat-spinner-32 lib Fixed size undefined error in tail method extension of class File. June 17, 2013
Octocat-spinner-32 log new model constructs February 24, 2012
Octocat-spinner-32 spec Turn YAML option data into Ruby code option data April 16, 2013
Octocat-spinner-32 test_scripts Last round of changes to make the Data object a singleton. All rspec … May 15, 2012
Octocat-spinner-32 tmp new tmp folder March 29, 2012
Octocat-spinner-32 .autotest Massive complete rewrite of almost everything in prep for making this… March 01, 2012
Octocat-spinner-32 .gitignore Add PuppetLabs packaging automation support to Rake December 26, 2012
Octocat-spinner-32 .mailmap Create a mailmap to fix incorrect author names November 29, 2012
Octocat-spinner-32 .yardopts new model constructs February 24, 2012
Octocat-spinner-32 CONTRIBUTING.md Update contributor license agreement URL March 11, 2013
Octocat-spinner-32 Gemfile Script Broker March 26, 2013
Octocat-spinner-32 LICENSE Publish the Project Razor project governance documents October 29, 2012
Octocat-spinner-32 README-old.md Import "The road forward for Razor" as the primary readme July 15, 2013
Octocat-spinner-32 README.md Update README.md with more prominent pointers to the rewrite August 21, 2013
Octocat-spinner-32 Rakefile (packaging) Use the packaging loader for tasks June 24, 2013
Octocat-spinner-32 TESTING.md Update test documentation to reflect unit test creation February 21, 2013
Octocat-spinner-32 project_razor.gemspec Use correct homepage in gemspec August 18, 2013
README.md

The road forward for Razor

TL;DR: Razor is being rewritten. You can find the rewritten code bases in the following repos:


During it's fairly short lifespan so far, Razor has shown that there is considerable demand for a policy-driven provisioning tool based on discovery of nodes. The thriving, and growing, community, and the fact that other tools are adopting Razor's approach are ample proof of that.

Over the last year, we've also learned a lot about the community's needs and how Razor should evolve, and about the limitations of Razor that make evolution harder than it needs to be. This knowledge has brought us to the conclusion that Razor's community and future development are best served by a rewrite of the current code base. The rewrite will carry the important and unique features of Razor forward, such as node discovery via a Microkernel, provisioning based off tagging nodes and policy, and flexibility in controlling the provisioning process. It will also change the code base in a way that we feel makes Razor more supportable and maintainable.

The rewrite will reach a state where the rewritten Razor is pretty much feature-equivalent with the current implementation by the end of August (puppetconf, really).

Overview

The cornerstones of the Razor rewrite are:

  • it will be based on widely adopted and well-understood web technologies: it will be written entirely in Ruby using Sinatra as the web framework, Sequel as the ORM layer, and PostgreSQL as the database. Among other things, this makes it possible to use associations in the object model, and provide transactional guarantees around complex operations.

  • tagging will be controlled by a simple query language; this makes it possible to assign tags using fairly complicated logical expressions using and, or, comparison operators, or even checks whether a fact is included in a fixed list (e.g., to associate a tag with a fixed list of MAC addresses) the current system of models will be greatly simplified, and models can be described entirely in metadata, without needing to write Ruby code (see below)

  • RESTful API's to query existing objects; command-oriented API to control the provisioning setup; authentication for all the API's (except for the server/node communication, which is pretty much impossible to secure); separate URL structures for the management and node/server API to make it easier to restrict those separately

  • the Razor-specific microkernel functionality will be broken out more clearly from the underlying substrate, making it easier to experiment with alternative microkernels

  • the main microkernel will be based off RHEL/CentOS to provide an easy way for users to do hardware discovery with a kernel that is known and certified to work on their hardware

  • since Razor controls the node during installation, broker handoff should be driven off the node, supported by stock broker scripts that ship with Razor

Controlling installation

Currently, installation is controlled by models, which consist of a state machine, file templates, and some helper code for those templates. The same functionality can be provided by a simpler approach: the only place where (server-side) state matters during installation is in determining how to respond to repeated reboot requests from the node - usually, the sequence is 'boot installler on the first boot after policy is bound, boot locally afterwards'.

Everything else that happens during installation falls into three categories:

  • retrieve a file; the file is the result of interpolating a specific template (e.g., kickstart file, post install script etc.)
  • log a message and associate it with the node
  • report node-specific data (really only its IP address) back to the server

All three of these are easily done on the server-side by a standard web application.

An installer (i.e., what used to be called a model) then really consists of two ingredients: (1) a metadata description that contains things like name, os name and version, as well as instructions on how to respond to repeated boot requests (2) a number of ERB templates that the node can request during the installation process.

This will make adding custom installers very easy, and allow for adding them entirely through the API.

Something went wrong with that request. Please try again.