Permalink
Commits on Feb 25, 2012
  1. Added a command to reboot the node if a "reboot" action is received i…

    Tom McSweeney committed Feb 25, 2012
    …n a checkin-reply
Commits on Feb 24, 2012
  1. New version of the Microkernel that has been refactored to separate the

    Tom McSweeney committed Feb 24, 2012
    "registration" action from the "checkin" action.  This version includes a
    daemon service that sends out a periodic checkin to the Razor server and
    reacts to commands received in the reply to that checkin request.  There
    is a separate "configuration agent" and WEBrick server that are used to
    push out a Razor configuration (a JSON-ized Hash Map) to nodes.  This
    configuration (and any later configuration changes) is pushed out through
    the MCollective (via the configuration agent running on each node) and
    that agent interacts with the WEBrick instance to save the configuration
    (if it has changed) to the Microkernel's filesystem and to force
    a restart of the Microkernel Controller (again, only if the configuration
    is different from the configuration that was received from Razor previously).
  2. Added code to check for changes in the configuration; am now only sav…

    Tom McSweeney committed Feb 24, 2012
    …ing the configuration just received from the Configuration Agent and restarting the Microkernel Controller's daemon process if the configuration just received is different from the configuration received previously.
  3. Initial version of the next release of the Microkernel (v0.1.0.0). Is…

    Tom McSweeney committed Feb 24, 2012
    … a fairly significant change from the previous release of the Microkernel (v0.0.2.0). There are now two servers running in the Microkernel: a Ruby daemon script (the Microkernel Controller) that manages the checkin process with the Razor server and a WEBrick instance that, at the current time, only picks up configuration changes sent out across the MCollective, saves them, and then restarts the Microkernel Controller (which forces the controller to pick up the new configuration immediately). Will package up the ISO and build files for this release tomorrow (or perhaps later today is a better way to view it...it is kind of late)
  4. Implemented the last of the changes to enable the checkin command...w…

    Tom McSweeney committed Feb 24, 2012
    …ill have to test next
Commits on Feb 23, 2012
  1. Almost ready to enable the "checkin" action in this daemon process. W…

    Tom McSweeney committed Feb 23, 2012
    …ill complete work on it tomorrow.
  2. Cleaned up how state is handled when the node is registered (now pass…

    Tom McSweeney committed Feb 23, 2012
    …es the "last_state" in as an argument to the node registration methods). Also cleaned up the wait code in the rz_mk_control_server so that it properly handles the case where the time remaining in the sleep window is zero or negative (in which case it doesn't even try to sleep). Finally, cleaned up a few comments and a bit of code to make things more readable.
  3. Added a slightly modified version of the FactManager class back into …

    Tom McSweeney committed Feb 23, 2012
    …our codebase so that we could check the current facts and see if they've changed since the last successful registration of this Microkernel instance with the Razor server. Added code to save a timestamp in the FactManager class each time the fact_map is saved to the file indicated by the "prev_facts_filename" and made that field accessible (so that it can be checked in the main event loop in our rz_mk_contol_server daemon script to see if we've saved facts since the iteration started). Removed code from the old FactManager class that actually loaded the facts into memory each time the facts where checked (to see if they've changed since they were last loaded); instead the current_fact_map is passed in as an argument. Finally, stubbed out the code in the RzMkRegistrationManager class that will register a node if the facts have changed. Still need to add code to this class to deal with the keep-alive HTTP requests (make the request, parse the reply, and take action based on the action in the reply, if any).
Commits on Feb 22, 2012
  1. Small change (basically just changed where in the script the variable…

    Tom McSweeney committed Feb 22, 2012
    … is set that specifies which file is used to serialize the Microkernel configuration)
  2. Added "logger" instance back in (and added it to the constructor for …

    Tom McSweeney committed Feb 22, 2012
    …the RzMkRegistrationManager class). Also changed the name of the log file for the rz_mk_web_server to be consistent with the name of the script itself...
  3. A couple of small "cleanup" type changes...nothing significant, more …

    Tom McSweeney committed Feb 22, 2012
    …of a "neatness counts" sort of checkin
  4. Reworked yesterday's code changes a bit (refactoring names, reworking…

    Tom McSweeney committed Feb 22, 2012
    … the interactions betwen scripts, etc.). Also added hooks into the rz_mk_control_server to read the configuration and added code to sleep the appropriate amounts of time between iterations. Verified that the code works as it should under a "restart".
  5. Reworked yesterday's code changes a bit (refactoring names, reworking…

    Tom McSweeney committed Feb 22, 2012
    … the interactions betwen scripts, etc.). Also added hooks into the rz_mk_control_server to read the configuration and added code to sleep the appropriate amounts of time between iterations. Verified that the code works as it should under a "restart".
  6. First round of changes to refactor (now using a hash map for configur…

    Tom McSweeney committed Feb 22, 2012
    …ation; agent not just sets the configuration for the microkernel using a servlet running in the WEBrick server instance, a separate rz_mk_controller has been defined that will control the rz_mk_control_server, and the rz_mk_control_server will send out the keep-alive signal to the Razor server and take action based on the reply it gets back in reponse to that keep-alive signal). More work is required before we have a working set of services for the Microkernel, but it's a start
Commits on Feb 17, 2012
  1. Added dmidecode package to the Microkernel ISO (fixes an issue that w…

    Tom McSweeney committed Feb 17, 2012
    …as causing facter to report that the OS was running in a physical environment, even if it was in a virtual environment). In this new image, the dmidecode command is available at boot and the facter output is correct (showing correctly if the Microkernel is in a virtual environment or not and, if it is virtual, showing the type of virtual environment being used)
  2. Added dmidecode package to the Microkernel ISO (fixes an issue that was

    Tom McSweeney committed Feb 17, 2012
    causing facter to report that the OS was running in a physical environment,
    even if it was in a virtual environment).  In this new image, the dmidecode
    command is available at boot and the facter output is correct (showing
    correctly if the Microkernel is in a virtual environment or not and, if
    it is virtual, showing the type of virtual environment being used)
Commits on Feb 16, 2012
  1. Added TO DO list to the README file

    Tom McSweeney committed Feb 16, 2012
  2. Changed URL-related references in the codebase to URI-related referen…

    Tom McSweeney committed Feb 16, 2012
    …ces instead. Also added code to catch the case where the factMap had not changed but the Registration URI had. Eventually will want to modify this code so that the factMap is saved to disk as a Hash Map (with the key being the Registration URI) so that we can have more than one registration server...
  3. Changed URL-related references in the codebase to URI-related referen…

    Tom McSweeney committed Feb 16, 2012
    …ces instead. Also added code to catch the case where the factMap had not changed but the Registration URI had. Eventually will want to modify this code so that the factMap is saved to disk as a Hash Map (with the key being the Registration URI) so that we can have more than one registration server...
  4. Changed URL-related references in the codebase to URI-related referen…

    Tom McSweeney committed Feb 16, 2012
    …ces instead. Also added code to catch the case where the factMap had not changed but the Registration URI had. Eventually will want to modify this code so that the factMap is saved to disk as a Hash Map (with the key being the Registration URI) so that we can have more than one registration server...
Commits on Feb 15, 2012
  1. First version of a WEBrick-based Microkernel Controller. With this ch…

    Tom McSweeney committed Feb 15, 2012
    …ange, can now get rid of the rz_mk_controllerd.rb script (since we now have a proper Microkernel Controller), but required changes to the configuration agent and the rz_mk_init.rb script. Also factored out the Facter-related code into a separate utility class.
Commits on Feb 14, 2012
  1. Commit to tag the current release...

    Tom McSweeney committed Feb 14, 2012
Commits on Feb 12, 2012
  1. New versions of the Microkernel ISO file (and the gzipped tarfile tha…

    Tom McSweeney committed Feb 12, 2012
    …t contains all of the files needed to build that ISO file). This version of the Microkernel adds the ability to exclude some of the facts gathered by Facter (based on whether or not their name matches a pre-defined "exclude" pattern) from the set of facts reported to the Razor server during the registration process. This version of the ISO also actually POSTs these facts to the server that should be running at the registration URL (previous versions just output what would be posted to the logfile). Finally, the output to the logfile in this version has been changed so that all of the messages are debug messages. This is in anticipation of a time when most of these messages will not be output to the logfile (and additional, error output messages will be added).
  2. New versions of the Microkernel ISO file (and the gzipped tarfile that

    Tom McSweeney committed Feb 12, 2012
    contains all of the files needed to build that ISO file).  This version
    of the Microkernel adds the ability to exclude some of the facts gathered
    by Facter (based on whether or not their name matches a pre-defined
    "exclude" pattern) from the set of facts reported to the Razor server
    during the registration process.  This version of the ISO also actually
    POSTs these facts to the server that should be running at the registration
    URL (previous versions just output what would be posted to the logfile).
    Finally, the output to the logfile in this version has been changed
    so that all of the messages are debug messages.  This is in anticipation
    of a time when most of these messages will not be output to the logfile
    (and additional, error output messages will be added).
  3. Latest bug fixes, still chasing a bug in the post

    Tom McSweeney committed Feb 12, 2012
Commits on Feb 11, 2012
  1. Changed MCollective Agent related test scripts so that they set their…

    Tom McSweeney committed Feb 11, 2012
    … load path to a location where the MCollective package has been installed. The Ubuntu MCollective package that is installed using "apt-get" also installs Ruby v1.8, which we want to avoid. Instead, have manually unpacked the MCollective tarfile in the /usr/share subdirectory (into a directory called "/usr/share/mcollective". The LOAD_PATH modification in these two scripts reflects that path.
  2. Modified code to output "properly formatted" JSON hash in the POST op…

    Tom McSweeney committed Feb 11, 2012
    …eration. Also modified the "excludeFactsPattern to also exclude memory-related facts (previously only excluded uptime-related facts) when constructing the factMap that is sent in the POST operation.
Commits on Feb 10, 2012
  1. Fixed bug in Microkernel Controller (state for facts wasn't defined..…

    Tom McSweeney committed Feb 10, 2012
    ….set it to "idle" for now)
  2. Changed paths for temporary files (now created in '/tmp' instead of '…

    Tom McSweeney committed Feb 10, 2012
    …/var/run'). Also added code to exclude the facts who's names start with the string 'uptime' from the facts reported to the registration URL and added code to construct a properly formatted URL for use with Razor. There will be one more change after this to actually enable the post...
  3. Refactored the name of the "Microkernel Controller Control" script (i…

    Tom McSweeney committed Feb 10, 2012
    …t's now rz_mk_controllerd.rb) and modified the rz_mk_controller.rb itself so that it only posts the facts to the registration URL if they are different from the last time they were posted. Eventually, will add a "keep alive" event that will be posted to the registrationURL (or a different URL?) in the event that no facts have changed (and this will give the server a chance to request a new set of facts from the Microkernel Controller if it doesn't have facts for that node, or if it thinks the facts that it has may be out of date)
Commits on Feb 9, 2012
  1. added "test client" that can be used to interact with the Facter Agen…

    Tom McSweeney committed Feb 9, 2012
    …t to the project
  2. Added a new configuration agent to the Microkernel image. This agent …

    Tom McSweeney committed Feb 9, 2012
    …currently has a single action (set_registration_url) that takes a URL as an argument and saves that URL (as a string) in a file on the Microkernel's filesystem. Also, created an instance of a test client that can be used to change the URL on all of the Microkernel instances in the MCollective. Finally, added code to the Microkernel Controller that pulls the URL from the file created by the Configuration agent. That URL will eventually be used by the Microkernel Controller as the target for a PUT operation (one that will register the facts for the node with the Razor server), but for now the target and the facts for that node are just output in the Microkernel Controller's logfile.
    
    Created a new ISO image and updated the tarfile in the Build-Files directory so that it contains the files necessary to build that ISO image.