Permalink
Browse files

Updating the README files to reflect the new Microkernel version (v0.…

…1.5.0)
  • Loading branch information...
Tom McSweeney
Tom McSweeney committed Mar 6, 2012
1 parent 5aaa381 commit e881b91881a1b675404bf0f62082d5029ca1bd6b
Showing with 72 additions and 44 deletions.
  1. +1 −1 README
  2. +71 −43 README2
View
2 README
@@ -1,7 +1,7 @@
This project contains the Ruby scripts/classes that are used to
control the Razor Microkernel (and that interact with the Razor server).
The files contained in this project are bundled into the current version
of the Razor Microkernel (v0.1.2.0). There are three primary services that
of the Razor Microkernel (v0.1.5.0). There are three primary services that
are included in this project that are started up during the Microkernel boot
process. Those services include:
View
114 README2
@@ -30,15 +30,16 @@ a copy of the contents of the Core-current.iso file). As such, the "newiso"
subdirectory contains all of the contents of the ISO file that we are using
in the Razor project.
If the iso-build-files.tar.gz tarfile is extracted, the microcore-current-files
subdirectory contains an another file (in addition to the three directories
mentioned above). That file is a shell script (rebuild_iso.sh) that can be
used to build a new ISO after changes are made to the contents of the "tmp"
or "newiso" directories. The shell script will run all of the appropriate
commands (there are about 8 of them) to build the new core.gz file,
place it in the appropriate location in the newiso directory, and then build
the new ISO from the contents of that directory. When the script finishes,
a new ISO will be built that can be used to boot machines.
If the iso-build-files.tar.gz tarfile is extracted, the within the
microcore-current-files directory that is created you will find a
tcl-4.2.1-files subdirectory contains a shell script (in addition to the three
directories mentioned above). This shell script (rebuild_iso.sh) can be used
to build a new ISO after changes are made to the contents of the "tmp"
directory. The rebuild_iso.sh script will run all of the appropriate commands
(there are about 8 of them) necessary to build a new verison of the core.gz
file, place it in the appropriate location in the newiso directory, and then
build the new ISO from the contents of that (newiso) directory. When the script
finishes, that new ISO can be used to boot machines (virtual or otherwise).
The second file is the Microkernel image itself (which is distributed in the
form of an ISO). There are two versions of Tiny Core Linux that have been
@@ -58,7 +59,7 @@ When these ISOs are used as the boot image for a node, scripts will
automatically be run after the node boots that will start an SSH daemon
and the MCollective daemon, a WEBrick instance, and the Microkernel
Controller daemon. Once the MCollective daemon is started, the node
can be controllable from the MCollective Control Node.
can be controllable from an MCollective Control Node.
At this time, the MCollective daemon's configuration (which appears in the
/usr/local/etc/mcollective directory of the Microkernel's filesystem) is
@@ -87,15 +88,20 @@ the current version of the Razor Microkernel (v0.0.2.0):
b. Installs the Bundler RubyGem
c. Uses the Bundler RubyGem to install the stomp, facter,
daemons, json_pure, and bluepill bundles
d. Run a Ruby-based initialization script that completes
the process of setting up the Microkernel for use
Once the stomp bundle is installed, that same script changes the
This initialization script (rz_mk_init.rb) changes the
hostname (in the /etc/hosts and /etc/hostname files using the 'sed'
command and also logically using the 'hostname' command) and then
starts the MCollective agent (but it only performs these two tasks
after the network is available; this ensures that MAC address for
the 'eth0' adapter is available through Facter and the that
the MCollective agent will be able to establish a connection to
the MCollective Control Node).
command and also logically using the 'hostname' command), then
starts a Ruby-based Microkernel Controller daemon, a Ruby-based
Web Server (a WEBrick instance), and the MCollective daemon.
These tasks are only run after the Microkernel's network has been
initialized (which can take several seconds after the boot process
completes), in order to ensure that MAC address for the 'eth0'
adapter is available through Facter and the that the MCollective
agent and Microkernel Controller will be able to communicate with
the Razor Server/MCollective Control Node.
3. We have added a pair of MCollective agents to the
/usr/local/mcollective/plugins/mcollective/agent subdirectory.
@@ -104,11 +110,12 @@ the current version of the Razor Microkernel (v0.0.2.0):
second agent (facteragent.rb) provides access to "Facter" on
each instance of the Microkernel through the MCollective.
4. We have constructed a wrapper (rz_mk_controller.rb)
around the rz_mk_control_server.rb script that daemonizes the
latter script and allows us to easily control it from the
command line using the former. The usage for the "control"
script is as follows:
4. The Microkernel Controller (mentioned in #2, above) is basically
just a wrapper script (rz_mk_controller.rb) that has been placed
around the real (rz_mk_control_server.rb) Microkernel Controller
script in order to daemonize the latter script and provide for
easy control over the latter script from the command line. The
usage for the "Microkernel Controller" script is as follows:
Usage: rz_mk_controller.rb <command> <options> -- <application options>
@@ -146,27 +153,48 @@ the current version of the Razor Microkernel (v0.0.2.0):
to a file and restarts the Microkernel Controller. This forces an
update to the Microkernel Controller's configuration.
6. One of the Microkernel Controller configuration options is a pattern
that defines which of the Facter "facts" (if any) should be
excluded from the registration details that are passed to the
Razor server by the Microkernel Controller. Currently, only "facts"
that have names that start with the string "uptime" or "memory" are
excluded, but this could be changed later.
7. The Microkernel Controller POSTs a JSON-formatted string representation
of the facts discovered using Facter to the registration URI received
from the Configuration agent. This "registration" procedure is triggered
any time that the Microkernel Controller detects a change in the facts
that it has gathered (versus the facts last reported to the Razor server
using this same registration procedure). The node will not register
with the Razor server until it has received a configuration that includes
the URI that it should register with. This functionality will be
triggered by a service in the Razor server that periodically sends
out the registration URI (perhaps even a different URI to different
types of nodes), but (for now) this functionality can be triggered
directly from the MCollective Control Node using the
'test-configuration.rb' script (which can be found in the
'configuration-agent' subdirectory). An example of using this
6. One of the Microkernel Controller configuration options is a
pattern that defines which of the Facter "facts" (if any) should
be excluded from the registration details that are passed to the
Razor server by the Microkernel Controller. Currently, only
"facts" that have names that start with the string "uptime" or
"memory" are excluded, but this could be changed later.
7. The Microkernel Controller periodically checks in with the
Razor server, and the periodicity of this "checkin" action being
set as part of the Microkernel Controller's configuration (the
initial periodicity that is "burned into" the ISO (which can be
overridden later) is 60 seconds. This "checkin" takes the form
of a POST to the Razor Server, and the Razor Server replies with
an action that the Microkernel Controller should take (currently,
the only actions supported are an "Acknowledgement", which
results in no action, a "Register", which causes the node to
Register with the Razor Server, and a "Reboot", which causes
a reboot of the node immediately.
During the Registration process, the node POSTs a JSON-formatted
string representation of the facts discovered using Facter to the
registration URI received as part of it's configuration. This
"registration" procedure will also be triggered any time that the
Microkernel Controller detects a change in the facts that it has
gathered (versus the facts last reported to the Razor server using
this same registration procedure).
The initial "checkin" that the node makes is back to the
"next-server" that the node used during the iPXE-boot process.
Typically, this initial "checkin" will trigger a registration and,
possibly, a restart of the Microkernel Controller when the initial
configuration is received from the Razor Server in the reply to the
initial checkin-message. If the configuration changes from one
checkin to the next, then the Microkernel Controller will POST the
new configuration to the Microkernel Web Server, which will save
the new configuration and restart the Microkernel Controller.
This functionality could also be triggered via the MCollective
(using the configuration agent that is included in the Microkernel
ISO), and an example script is included to show how this might
be done from within a Ruby script (the 'test-configuration.rb'
script, which can be found in the 'configuration-agent'
subdirectory of this project). An example of using this
script from the command line is something like the following:
# test-configuration.rb mk_conf.yaml

0 comments on commit e881b91

Please sign in to comment.