Fixes #395 (Complex Razor Microkernel version numbers not handled properly); changes made in December of 2012 to handle the more complex version numbers that could be generated by the, at the time, newly revised Microkernel ISO build process led to issues when comparing newer, stable versions of a Microkernel with older, patched versions of the Microkernel.  The code that calculate the weights used to determine which to load was not calculating these numbers correctly.  This change should resolve that issue by calculating the weights as floating point numbers (with the part after the decimal being the commit number and the part before the decimal being an integer representation of the latest tag) instead of comparing these versions as integer numbers (which did not work...older, patched versions were preferred over newer, unpatched versions).
Add BuildArch of noarch to the redhat spec

When no BuildArch is present in the specfile, rpms will be built assuming the
build is arch specific. As razor is pure ruby, there is no compilation needed
and it should be a noarch package, so this commit adds a BuildArch of noarch to
the specfile.
Remove leading epoch from spec file changelog

This looks like a lingering artifact from the facter spec file. There was an
epoch of 1 in the spec file previously, and so the changelog had a leading 1 in
the version section. That wouldn't have affected the package but could be
confusing to those reading the changelog. This commit removes that epoch from
the changelog.
Modified weight calculations further to properly handle the new semantic version numbering scheme being applied to the Razor Microkernel project (so that v0.10.0 will evaluate higher than v0.9.3.0)
Merge pull request #396 from tjmcs/tb/fixes-rz-mk-versioning-problem

(#395) Complex Razor Microkernel version numbers not handled properly
Merge pull request #394 from haus/specfile_fixups

Redhat spec file fixups
(#388) Update to handle three flavours of Microkernel

During the earlier builds I forgot that we build three flavours of
Microkernel, the production, development, and debug types.  The tests and
other CI infrastructure then only tested one, which was not sufficient for
the project.

This fixes up the internal repo layouts to respect the three different types,
and enables testing and releasing all of the different flavours in our nightly
builds area.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #397 from daniel-pittman/feature/master/388-handle-updated-internal-package-repo-layout

(#388) Update to handle three flavours of Microkernel
(#388) Correctly update to handle three flavours of Microkernel

My previous fix to the handling of the Microkernel flavours used the wrong
build parameter names, to my embarrassment, and my local testing didn't pick
that up as it also used the wrong names.

Hilarity, and this commit, ensue.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #398 from daniel-pittman/feature/master/388-handle-updated-internal-package-repo-layout

(#388) Correctly update to handle three flavours of Microkernel
Fix shell interpolation in Ruby strings...

Apparently I have been writing too many shell scripts recently, because the
dollar sign is not how you trigger interpolation in a Ruby script.

This fixes that to use Ruby interpolation, resulting in a string that works
the way it was expected.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #399 from daniel-pittman/feature/master/388-handle-updated-internal-package-repo-layout

Fix shell interpolation in Ruby strings...
Update the build status badge URL

The name of the acceptance test suite has changed; this updates
the image URL for the status badge in the readme file to match.
Actually fix the image URL

This pastes the correct URL into place... *sigh*
Update internal acceptance test hostname

This updates the internal hostname of the acceptance test machine
we use for testing changes.
(#403) Requiring require_all in broker.rb

This change requires require_all in the broker.rb file the same was as
in the model.rb file. This removes the need to explicitly require each
broker under the correspondingly named subdirectory.

The change is desirable because it enables people writing custom brokers
to just drop their Ruby file under the broker subdirectory and have it
required automatically by Razor.
Fixed issue with the Razor daemon ignoring the node_expire_timeout value.
Modified the Razor daemon so that it uses the new (not sure how new)
syntax added recently to separate out slices that provide a "JSON interface"
from those that provide a "Web interface".  It turns out that invoking a
"razor -w config" command now returns an "InvalidSlice" error rather than
returning the current configuration for the Razor server...the new syntax
that must be used to obtain the configuration is "razor -j config" (and this
change in syntax had not been propagated out to everywhere that we were
using the older "razor -w config" command, including the razor_daemon.rb
script where the result was that the node_expire_timeout value contained in
the Razor configuration was being ignored and a default (15 minute) value
for this node_expire_timeout parameter was being used instead.
Merge pull request #406 from tjmcs/tb/fix_razor_config_slice_error

Fixes #405 (Razor daemon ignoring the node_expire_timeout value)
(#401) Checking network status with nm-online

This change checks the network status at the top of the os_boot.erb
template for Red Hat 6 so that the script can connect to the Razor
daemon over the network. This is done by checking the status of
the NetworkManager service and calling the nm-online command, when
it's available, with a reasonable timeout that returns as soon as the
network is online. The command and the timeout values are taken from the
NetworkManager init script from CentOS, so it should be sane and should
not introduce any regressions.

The change is necessary in the context where a Red Hat derivative uses
Anaconda which configures the network with Network Manager. This is an
asynchronous process so the network might still be offline when rc.local
is called so the boot process never completes the handoff to the broker.
You must start Razor when running the tests

Our testing guide missed an essential step:

Because we only have acceptance style tests, not unit tests, it is
necessary to manually start the Razor daemon process before running
the test suite.

This updates the document to reflect that sadly omitted step.