[Persist] Add persist_username & persist_password to Config::Server.

Currently there is no mechanism to pass authentication credentials to a
local or remote persistence service (such as MongoDB or PostgreSQL).
While a non-authenticated connection works out of the box with a local
MongoDB server, this is not the case with a local PostgreSQL server.

Furthermore there is no way to configure Razor to use a remote MongoDB
server protected by a username/password authentication.

As a result the PersistPlugin#connect method signature was augmented to
take `username` and `password` parameters. Each persistence
implementation is responsible for using or ignoring these additional
parameters when establishing a database connection.
[Postgres] Bugfix: uuid variable not defined in #object_doc_get_by_uuid.
[Postgres] Ensure Ruby symbols are (de)serialized.

In the MongoPlugin Ruby symbols are preserved in hash values thanks to
BSON, but in other persistence plugins symbols will be coerced to
strings (via a JSON.generate in the Postgres case) before saving. When
the object is deserialized the values that were Ruby symbols are now
strings which is not expected by the rest of the codebase.

Instead, we can "encode" the hash data structures containing symbols by
transforming any symbols to strings, for example: :symbol -> ":symbol".
When the data is read back out of the database we can "decode" these
data structures and reconstitute the symbols.
[Postgres] Allow ID of type VARCHAR only for policy_table.

A single row is inserted into this table with a "uuid" set to
"policy_table" which is not a valid UUID.
[Postgres] Insert active_model object if '@version' attr is < 0.

The object document that is persisted to the :active collection is a
PolicyTemplate and as such will have a version attribute greater than 1.
Disentangle configuration access from the data store layer

Before this change an awful lot of the Razor code accessed the global
configuration through the "data" object - because the database abstraction
happened to load the configuration file, all the rest of the code connected to
the database to access the side effect of configuration data.

The database abstraction also owned loading and updating the configuration
file on disk, tying the two together in very intimate ways that, generally,
don't make a lot of sense.

This extracts a bunch of logic around configuration file handling from the
data store, puts it in the configuration class, and then builds a global
configuration accessor off the project to provide access.

This is, in essence, a change from `get_data.config['whatever']` to
`ProjectRazor.config['whatever'`, which seems like an overall win.

Really, this is code cleanup and lays the groundwork for changing the data
abstraction layer in more fundamental ways tomorrow.  The goal is not to
change fundamental behaviours, just to clean up the code that builds them.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #429 from daniel-pittman/feature/master/323-extract-and-sanitize-config-handling-for-persistence-layer-updates

Disentangle configuration access from the data store layer
Load `mocha/api` in order to cleanly integrate with rspec

The newest versions of the Mocha library require that we load `mocha/api` when
integrating with a non-core test library.  Given we use rspec exclusively,
this updates the code to match their polite request.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Strip the config testing out of the persistence layers test suite

The acceptance tests for the data object still made assertions about the
configuration; this eliminates that, now that we have separated it from the
persistence layer.

All the testing that this performed has also been ported to the regular unit
test suite, so there is no loss in eliminating this change.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Eliminate use of config through the persistence layer in tests

The acceptance suite had a bunch of uses of the configuration data through the
persistence layer that, for some crazy reason, didn't show up in my earlier
test runs.

This eliminates those, allowing the tests to actually pass when fully run,
after the initial work disentangling the two concepts in the code.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Migrate MK boot policy tests from acceptance to unit framework

This copies the tests of the Microkernel boot policy tool into the unit test
suite, rather than the acceptance test suite.  The same tests are performed,
but now in a way that doesn't depend on the rest of the infrastructure of a
fully operational Razor installation.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Update tag slice tests to work regardless of IP in configuration file

The tag slice acceptance tests were trusting the content of the Razor
configuration file to locate their next step - even if that was mutable state
changed by other tests.

This updates them to simply assume the Razor instance they are testing is
running on localhost in *all* of their URLs, rather than just the ones that
start the testing process.

This ensures that the tests pass with less need to assume a previous test has
reset configuration on disk to the system defaults.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Fix in-memory persistence layer collection handling

The in-memory persistence layer was implemented with some incoherence, and
handled indexing to locate a specific document incorrectly.  It tried to treat
an array of all instances as a hash, rather than finding the record directly
in memory.

As a side effect I was able to delete a few extra lines of code by eliminating
one stateful variable, and using a Ruby feature to fill in blank values in the
target hash appropriately.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add basic test for `razor policy add`

This adds a basic unit test for the policy slice, around adding a new record;
it attempts to validate the end to end success case, inspired by the failure
noted in #431 - our existing tests didn't discover the failure mode for
configuration access in an inappropriate location.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Fix the server configuration spec for the in-memory persistence update

The configuration object in Razor is stateful.  This means that change
propagates between our tests freely, if they run in the same Ruby VM, and we
end up with the "use in-memory persistence" configuration in the global
helpers causing failures in the config specs.

To combat this the global state is now reset in the configuration code tests,
to ensure that we continue to enter them in the state that we believe we
should be in.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #433 from daniel-pittman/bug/master/431-razor-policy-add-fails-after-config-cleanups

#431 razor policy add fails after config cleanups
(#323) Fix final URL related bug in configuration related acceptance tests

The earlier merge was tested improperly, and wound up full of breakage that
only showed up in the "live" CI system, not on the bench.  While that sucked,
most of the issues were patched.

This one missing URI parsing issue seems to be the last real failure in our CI
system, and with that changed to not double-parse a URI, should give us a
fully functional test suite again.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #434 from daniel-pittman/bug/master/323-additional-acceptance-failures-after-cleanup

(#323) Fix final URL related bug in configuration related acceptance tes...
Merge PostgreSQL plugin fixes from blueboxgroup

This fixes some of the more obvious and painful bugs in the PostgreSQL storage
plugin added a little while back.  It doesn't address core issues like
application level model corruption from concurrent activity on the database,
but it makes it more practical to use PSQL during testing of the current
preview releases.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Script Broker

A simple broker that executes a script on the node. This provides a
lightweight broker with no external service dependencies. It is suitable
for one-time configuration post os install, but also flexible enough to
setup more complicated long term solutions (e.g. local puppet apply).

Features:

 * Optionally send auxillary data along with the script.
 * Sends the metadata along with the script.
 * Fully configurable where the files land on the node.

Interface:

The script will be called with one parameter: The path to the metadata file.
The metadata file contains all the node metadata (including tags) and the
configuration of the script broker (including the paths to local resources). It
is JSON 'pretty' formatted and should be amiable to parsing.

Example:

  On the Razor Server:

    # cat /root/hello_world.sh
    #!/bin/bash
    set -e
    set -u

    echo "Hello World!"
    echo "Metadata Path: $1"

    # razor broker
    Broker Targets:
     Name =>  hello_world
     Description =>  Hello
     Plugin =>  script
     UUID =>  4kp0o3tchb5NW5pdcV6pRf
     Script =>  /root/hello_world.sh
     Script Path =>  /tmp/razor_script
     Data =>
     Data Path =>  /tmp/razor_script_data
     Metadata Path =>  /tmp/razor_script_metadata
     Log Path =>  /tmp/razor_script.log

  On the Node after the script broker has run:

    # cd /tmp
    # ls
    razor_complete.log  razor_script  razor_script.log  razor_script_metadata
    # cat razor_script.log
    Hello World!
    Metadata Path: /tmp/razor_script_metadata
    # cat /tmp/razor_script_metadata
    {
      "username": "root",
      "password": "electric",
      "metadata": {
        "razor_tags": "ubuntu-precise,cpus_16,virtualbox_vm,OracleCorporation,nics_1,memsize_1015MiB",
        "razor_node_uuid": "49jbMtCv4gn0BLphWfmJ8p",
        "razor_active_model_uuid": "4IfYuiaCQ1fY9D1mQUZ0Vr",
        "razor_model_uuid": "60WqyDfq9yF3HSSpLWutpf",
        "razor_model_name": "ubuntu_precise",
        "razor_model_description": "Ubuntu Precise Model",
        "razor_model_template": "linux_deploy",
        "razor_policy_count": "27"
      },
      "uuid": "49jbMtCv4gn0BLphWfmJ8p",
      "ipaddress": "10.0.1.123",
      "script": "/vagrant/echo_script.sh",
      "script_path": "/tmp/razor_script",
      "data": "",
      "data_path": "/tmp/razor_script_data",
      "metadata_path": "/tmp/razor_script_metadata",
      "log_path": "/tmp/razor_script.log"
    }