My big, exciting, fabulous TorqueBox migration!

This moves from MRI to JRuby under TorqueBox as the primary runtime for
razor-server.  This move brings a large pile of features to the table, such as
real messaging and background tasks, clustering support, and threads, that
allow us to effectively deliver the uptime and capabilities that
Razor deserves.

After this change it is no longer supported to run or develop Razor with MRI.

The readme includes more detailed instructions, but the gist:

1. Install JRuby 1.7.4
2. `bundle install`
3. `torquebox deploy`
4. `torquebox run`
5. `curl http://localhost:8080/api`

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add SimpleCov to the spec suite for coverage tracking

This adds SimpleCov as a mandatory feature of the spec suite.  Given the
performance with and without is identical, this seems like a net win.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Change to postgresql from postgres

Just jdbc:postgres was giving obscure errors and could not run "rake db:migrate".
Merge pull request #10 from eglute/bug/master/postgresql-config

Change to postgresql from postgres
Implement `compose_url` helper for Sinatra

This is a helper to wrap the process of building a URL from component parts,
some of which may need to be URL-escaped.  It takes many arguments, treating
each as a part of the 'relative to the app' URL, and composes them together.

Example:

    compose_url
    => '/'

    compose_url 'api', 'images'
    => '/api/images'

    compose_url 'api', 'images', image.name
    => '/api/images/correctly%20escaped%20name

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Create top level API navigation message handler

This handles an HTTP message fetching the API table: which endpoints are
available for use, and what do they do.  It includes testing and, as a side
effect, an assertion that the client is willing to accept our (only) content
response type across the board.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the `create_new_image` API message handler.

This implements the create new image message, which starts the process of
loading a new ISO image into Razor, along with creating and binding components
together to allow it to be used for later installation.

Much of the work happens in the background; this simply triggers the process,
after performing appropriate validation and transformation of the image.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the new image schema in the database

This updates the database schema, in the existing migration, to reflect the
current needs of the Image model as part of the command.  This removes a pile
of the existing data, which is not actually part of the new world
understanding of how images operate.

This also ties in the appropriate validation, ensuring that we have correct
data -- including assertions that the data passed to the command matches the
publicly modifiable parts of the model.

Some of the validation code is a little convoluted, to work around limits of
regular expressions that are compatible with both Ruby and PostgreSQL
semantics.  The great thing about POSIX regular expressions is how wonderfully
varied the implementations turn out to be.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement Sequel::Model message infrastructure for TorqueBox

This provides a general purpose message handler for routing messages to
Sequel::Model instances using the TorqueBox infrastructure.  Rather than
having hand-crafted message handlers for every message, this provides a single
instance of the "load the instance, send a message to it" pattern that shows
up time and again internally.

The expected use from a user point of view will be through a Sequel::Model
plugin, providing the syntax:

    Razor::Data::ModelDerivedClass.new(...).publish(message, arg, arg, arg)

That is, roughly analogous behaviour to `public_send`, modified by the fact we
will travel through a message queue.

Internally this uses the EDN encoding, via the `edn-ruby` gem, to encode and
decode values; unlike JSON, this is capable of representing Ruby symbols, and
Time objects, allowing higher fidelity transmission of message arguments
through the queue.

These messages are not intended for use outside the single class, so
interoperatibility is not a substantial concern in the choice of encoding, and
EDN is supported in TorqueBox out of the box.

This also adds a plugin that adds the sugary `publish` method to all
Sequel::Model instances, allowing callers to publish that message for later
consumption using the TorqueBox message queue.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the image file download workflow

Implement image download, and related behaviour, using the background
messaging capabilities of the image instance.  This makes the image accessible
as a local file, by downloading it if necessary, or by checking that it is
readable if a local file.

Once the file is accessible, a message is sent to the same instance to trigger
the unpacking of the file.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the image unpack workflow

This brings actual unpacking of images, using the external `7z` archiver, into
the codebase.  While imperfect, this is a reasonably inexpensive way to get
image unpacking working for arbitrary ISO (and, coincidentally, tar) images.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Move MK checkin `hw_id` from URL into JSON body

The MK checkin API had a somewhat inconsistent input: the node `hw_id` field
was supplied inline to the URL, but the facts were supplied in a nested JSON
map, allowing for other inputs.

This pulls down the `hw_id` from the URL into another field in the input JSON,
next to facts, to make the interface uniform.  Now, one place alone needs to
be consulted to understand what is happening -- and the JSON document is a
stand-alone record of what will change.

(That is: the document contains all the data required to reproduce the act, so
capturing the body alone is sufficient to have an audit trail of operations.
It still does not capture the intended operation -- that is "implicit" in the
surrounding environment, so this is not entirely sufficient to provide the
audit facility.)

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Make the template lookup for installers more flexible

Though we don't use it yet, it's now possible to have both templates stored
in the FS, and templates that are stored in the DB as text.
* db/migrate/002_create_base_schema.rb: move validation regexps to constants

We will want to use these for other validations, too
Allow storing installers in the DB in addition to the FS
* lib/razor/installer.rb (find): look for installers in FS and in DB
Add a 'create_installer' command
Documentation for the create_installer command