(#294) Fix missing hyphen in tag name

Hyphen is allowed in tag names, but was being stripped by a broken
regular expression. It needs escaping to be treated literally.

This fixes #294.
Changed all instances of "invert" in tag.rb to "inverse" to work properly with the tag matching capability of both Razor and puppetlabs-razor
Fixes issue #360; modified puppet broker plugin so that it uses a more widely accepted Bourne-style shell syntax to redirect both stdout and stderr when invoking the '/tmp/puppet_init.sh' script during the broker handoff process.  Previously, this script was invoked using the syntax '|&' to redirect both stdout and stderr to a 'tee' command, now the syntax '2>&1 |' is used instead (which works better with older versions of 'bash' and older versions of other Bourne-style shells)
(#366) Broken dependency on `which` in Debian packaging

The Debian packaging indicates a dependency on the package which, which does
not exist. The correct dependency is on the package debianutils which includes
the which(1) command - except that is an "essential" package, so we shouldn't
depend on it, we should just assume it is present.

This drops the dependency in the obvious way, fixing the problem, and
closing #366 along the way.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #367 from daniel-pittman/bug/master/366-incorrect-dependency-for-which-in-debian-packaging

(#366) Broken dependency on `which` in Debian packaging
Support the `mongodb-10gen` database as well as `mongodb`

We generally installed using the upstream 10gen packages of MongoDB, even when
there were distribution packages, with the git modules.  As part of smoothing
the migration between the two we should make the `mongodb-10gen` package
satisfy the dependencies of the Razor package.

That should allow both modes - distribution packaged mongodb, or upstream, to
work correctly as the developer wishes.

This is not an issue on the RPM side of the fence, since their policies forbid
any direct dependency between our package and the storage engine.

This closes #368.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #369 from daniel-pittman/bug/master/368-support-mongodb-10gen-package

Support the `mongodb-10gen` database as well as `mongodb`
Merge pull request #364 from tjmcs/tb/fixes-issue-360

Fixes issue #360; redirect of stdout and stderr to 'tee' changed from `|&` to `2>&1 |`
Add a brief document on how to run tests

There was no guidance in the repository about the steps required to run tests,
and those are not completely obvious.  We should improve the tests themselves
to work better, but for now we can get good millage out of documenting
everything at a lower cost.

This closes #370.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Support multiple razor install types in acceptance suite

In order to transition smoothly from git to packaged versions of Razor, there
needs to be a period when we support both, so that we don't leave users high
and dry with a broken system.  Even an alpha product like this should care
about user experience at this level.

This enhances the acceptance test installer for Razor to support "package"
install mode, if we ask for `internal-packages` install mode.  The default
remains git, and we can explicitly request that also.

It also configured, in `internal-packages` mode, the internal apt package
repository that contains the artifacts of the last successful internal
package build.

Neither of those is expected to be useful from outside the walls of
Puppet Labs, but the general infrastructure will: when we establish public
package repositories, we will be able to integrate a test mode that uses
those, and ensure that we continue to pass acceptance tests with our packaged
product in the face of external change.

This is part of #307, but not sufficient to complete it.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Install the "spec" acceptance test suite to test servers

When we are running our acceptance test suite using packages, we end up
without the "spec" directory - which contains acceptance tests - installed.

That is sensible and correct, but means we need to transfer that from the git
checkout manually in order to actually test the product.

This closes #307.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #371 from daniel-pittman/feature/master/307-run-acceptance-test-using-packaged-artifacts

Feature #307 - run acceptance test using packaged artifacts
Puppet dislikes top level brace surrounded variables...

Apparently some versions of Puppet dislike `${foo}` at the top level, leading
to test failures with the message "Could not match ${foo}", which is awesome.

This corrects that - the unquoted variable is portable through all the
variants of the DSL, so solves the problem smoothly.

This is part of #372, but does not resolve it.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #374 from daniel-pittman/feature/master/307-run-acceptance-test-using-packaged-artifacts

Puppet dislikes top level brace surrounded variables...
pool.sks-keyservers.net GPG key server is unreliable

The `pool.sks-keyservers.net` machines occasionally time-out trying to fetch
the GPG key, which leads to an acceptance test failure - because we can't get
the key required to install Puppet, which means we can't install Razor.

We should make sure we at least try more than once to fetch the key, and
ideally use a second source so that we increase the chance of successfully
finding the public key material.

This shouldn't change the overall robustness of the system because all the
various key servers exchange keying data with each other routinely, and we are
not looking for keys that rapidly change.

This implements that, trying with `pgp.mit.edu` and then `keyserver.pgp.com`
if we fail on fetching the key from sks; that should be fairly robust.

Closes #375.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Added Razor init scripts for Debian and RedHat

This adds wrapper init scripts that smooth the path between the `daemons`
based Ruby script for starting the Razor service and the system.

That consists of providing the correct sequencing and packaging hooks to end
up invoking that Ruby script to perform the actual action.

This ensures that LSB tools, chkconfig, and related system integrations will
behave as expected when the packages are installed.

This closes #320 for now.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Razor packages must not overwrite git deployments

The general opinion of the community was that installing packages over the top
of an existing git deployment of Razor is a bad idea, and they should refuse
to install.

I tend to agree: that is the most conservative approach, and puts the
responsibility on the end user to decide how they want to handle the
change over.

This shouldn't last forever, but we should at least initially have pre-install
and pre-upgrade code that refuses to install if /opt/razor/.git exists.

This implements that using pre-install scripts to check for the git directory
being present - but only for the first install; upgrades ignore it, so that
managing configuration through git will work after that first install is
pushed through.

This closes #322.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Use fully-qualified VM hostname for internal tests

Using a fully-qualified VM hostname makes it much easier to run acceptance
tests over a remote network through the VPN - in turn, reducing friction when
it comes to building new acceptance tests.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Test packages refuse to install over git deployments

This adds an acceptance test to verify that we don't install packages over the
top of an existing git deployment.  This should help ensure that our
preinstall scripts actually work to abort in that case.

In the words of Knuth, "Beware of bugs in the above code; I have only proved
it correct, not tried it." -- in this case, I have verified it as far as I am
able, but limitations of internal package repositories, multiple Jenkins
deployments, and branch testing mean that I am unfortunately unable to run
this through a full CI suite in the real world.

Consequently I expect something to blow up when faced with reality, although
it should only be a minor deviation in the road.  (None of this is helped, of
course, by bugs in other products that make it harder to verify success or
failure than I might like.)

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #376 from daniel-pittman/feature/master/375-increase-gpg-key-server-robustness

pool.sks-keyservers.net GPG key server is unreliable