Skip to content
This repository

Merge pull request #79 from alexkonradi/enhancement/multiple-deb-pack…

…age-sources

Extend .deb package importing to support multiple sources
latest commit 32aa62fae2
tjmcs tjmcs authored
Octocat-spinner-32 additional-build-files Add lshw.deb to builtin-extensions.lst
Octocat-spinner-32 bin Make bin/deb2tcz.sh more robust
Octocat-spinner-32 etc Added code to the build-dependency-files.sh script to support two new…
Octocat-spinner-32 iso-build-files Merge pull request #55 from daniel-pittman/feature/master/better-fake…
Octocat-spinner-32 opt The stomp gem was only used to support MCollective
Octocat-spinner-32 razor_microkernel modified gem controller to parse new format for gem.list file correctly
Octocat-spinner-32 tmp This commit adds support for a gem mirror (either internal or, when c…
Octocat-spinner-32 usr Use multiple discovery methods for Razor's IP
Octocat-spinner-32 .gitattributes Committing the "bluepill" gem (and it's dependencies)
Octocat-spinner-32 .gitignore Adds built artifacts to the .gitignore
Octocat-spinner-32 .mailmap Add a mailmap to correct mismatched author names
Octocat-spinner-32 COPYING Update license to Puppet Labs GPLv2.
Octocat-spinner-32 LICENSE Update license to Puppet Labs GPLv2.
Octocat-spinner-32 README-old.md Import "The road forward for Razor" as the primary readme
Octocat-spinner-32 README.md Import "The road forward for Razor" as the primary readme
Octocat-spinner-32 build-bundle-file.sh Support multiple .deb package source URLs
Octocat-spinner-32 bundle.cfg.example Removes MCollective from the Razor Micro Kernel
Octocat-spinner-32 rz_mk_control_server.rb This commit adds support for a gem mirror (either internal or, when c…
Octocat-spinner-32 rz_mk_controller.rb Update license to Puppet Labs GPLv2.
Octocat-spinner-32 rz_mk_gem_mirror.rb This commit adds support for a gem mirror (either internal or, when c…
Octocat-spinner-32 rz_mk_gemrc.yaml This commit adds support for a gem mirror (either internal or, when c…
Octocat-spinner-32 rz_mk_init.rb Removes MCollective from the Razor Micro Kernel
Octocat-spinner-32 rz_mk_tce_mirror.rb Limits the services on port 2156 and 2157 to localhost.
Octocat-spinner-32 rz_mk_web_server.rb Limits the services on port 2156 and 2157 to localhost.
README.md

The road forward for Razor

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.

Status

We've started a strawman of the reimplementation; most of the work has gone into the server side so far. The current state of affairs can be found on github:

https://github.com/puppetlabs/razor-server https://github.com/puppetlabs/razor-el-mk

We'd love to hear your feedback, and hope to see both lots of discussion and patches to continue to make Razor the best provisioning tool out there.

David Lutterkert, and Daniel Pittman

Something went wrong with that request. Please try again.