Skip to content
Commits on Apr 11, 2012
  1. Last round of debugging and bug fixing. This is the version of the Ra…

    Tom McSweeney committed
    …zorMicrokernel::RzMkHardwareFacter class that will be included in the next version of the Microkernel (v0.4.2.0). Includes changes to properly parse "Unclaimed" lines and to properly handle the "lshw -c network" output (returning it as an array, even though it doesn't look like the other resource arrays). Also includes code changes to ensure that all of the meta-data values being added by these commands are returned in Hash maps and/or Arrays that are referenced from the attributes hash with keys that are prefixed by the string "mk_hw_TYPE_" where TYPE is one eof the following strings: "bus", "mem", "disk", "proc", or "nw" (for outputs from the "lshw -c bus", "lshw -c memory", "lshw -c disk", "lshw -c processor", and "lshw -c network" commands, respectively). In addition, the output of the "lscpu" command is returned under a single key in the attributes hash (mk_hw_cpu_info).
  2. Added two more lshw commands (to gather facts about the system and th…

    Tom McSweeney committed
    …e bus, the latter includes the board serial number for physical nodes, which can be used to tie the BMC and node information together)
  3. Changes to add a new set of "hardware-specific" facts to the list of …

    Tom McSweeney committed
    …facts reported during node registration. The new facts are gathered from the node by the Microkernel Controller using wrapped calls to "lscpu" and "lshw" system calls. Will complete testing of the new code tomorrow, but so far tests using a copy of this code in an external ruby script are working as they should.
Commits on Mar 21, 2012
  1. Changed the structure of the YAML file built by this script a bit so …

    Tom McSweeney committed
    …that we can use more than just a SHA256 checksum if we would like. The new YAML file now has a 'kernel_hash' and 'initrd_hash' field in it (replacing the 'kernel_sha2' and 'initrd_sha2' fields that were in this YAML file previously) and includes a 'hash_description' map in it that describes the hash algorithm that was used to generate the 'kernel_hash' and 'initrd_hash' values.
Commits on Mar 20, 2012
  1. Added two new fields to the YAML file built by the build_iso_yaml.rb …

    Tom McSweeney committed
    …file that contain the sha256 checksums for the vmlinuz and core.gz files contained in the ISO (used to check for integrity of these two files during the iPXE-boot process). Also changed the existing kernel and initrd fields in this file so that they included relative paths (from the root of the ISO) to these two files (boot/vmlinuz and boot/core.gz, respectively). Finally, made changes to the rebuild_iso.sh file so that the new CLI for the build_iso_yaml.rb file is used (now have to pass in 4 arguments, not just two; have added the paths to the kernel and initrd files as inputs to the build_iso_yaml.rb script)
Commits on Mar 11, 2012
  1. Added the scripts used during the process of building the Razor Micro…

    Tom McSweeney committed
    …kernel ISO to the project, will be available starting with this version of the Microkernel (v0.2.1.0)
Commits on Mar 7, 2012
  1. Refactored the "utility classes" in order to place them into their ow…

    Tom McSweeney committed
    …n module (the RazorMicrokernel module). At the same time, added a "RazorMicrokernel::Logging" mixin that can be used to make a component loggable (this mixin is patterned after the ProjectRazor::Logging mixin in the Razor project). Finally, made the changes necessary to replace the old "logger" code (where a Logger instance was created in the "main" scripts and passed into the associated methods) with the new mixin-based logger (where the capability to log is mixed into the scripts/classes). The only difficulty was in sorting out how to apply the new mixin-based logger in the WEBrick instance, but that issue has been resolved. This should complete the refactoring necessary to output logs in a manner that is equivalent to how logs are handled in the Razor project...
  2. Refactored the "utility classes" in order to place them into their ow…

    Tom McSweeney committed
    …n module (the RazorMicrokernel module). At the same time, added a "RazorMicrokernel::Logging" mixin that can be used to make a component loggable (this mixin is patterned after the ProjectRazor::Logging mixin in the Razor project). Finally, made the changes necessary to replace the old "logger" code (where a Logger instance was created in the "main" scripts and passed into the associated methods) with the new mixin-based logger (where the capability to log is mixed into the scripts/classes). The only difficulty was in sorting out how to apply the new mixin-based logger in the WEBrick instance, but that issue has been resolved. This should complete the refactoring necessary to output logs in a manner that is equivalent to how logs are handled in the Razor project...
  3. Refactored the "utility classes" in order to place them into their ow…

    Tom McSweeney committed
    …n module (the RazorMicrokernel module). At the same time, added a "RazorMicrokernel::Logging" mixin that can be used to make a component loggable (this mixin is patterned after the ProjectRazor::Logging mixin in the Razor project). Finally, made the changes necessary to replace the old "logger" code (where a Logger instance was created in the "main" scripts and passed into the associated methods) with the new mixin-based logger (where the capability to log is mixed into the scripts/classes). The only difficulty was in sorting out how to apply the new mixin-based logger in the WEBrick instance, but that issue has been resolved. This should complete the refactoring necessary to output logs in a manner that is equivalent to how logs are handled in the Razor project...
Commits on Mar 6, 2012
  1. A new version of the ISO (v0.1.6.0) that includes the changes necessa…

    Tom McSweeney committed
    …ry to dynamically change the logging level using the new parameter that was just added to the Razor Server configuration file (mk_log_level). While this functionality was being added, also did a bit of refactoring of the RzMkConfigurationManager class to further encapsulate the details of how the current configuration is persisted and managed internally. Now maintain the current configuration state within this class, and provide attr_readers that can be used to get this information from other classes (rather than requiring that those classes understand the particulars of the configuration map passed from the Razor Server).
Commits on Mar 3, 2012
  1. refactored the codebase and the mechanism for storing the Microkernel…

    Tom McSweeney committed
    … Controller configuration in order to work in changes implemented in Razor to return a Microkernel Controller configuration as part of the "Checkin Response". Required changes to the Razor Microkernel Controller, the Razor Microkernel Web Server, and the mk_conf.yaml file itself (in order to add the code to process the configuration from the Checkin Response and to account for changes made to the configuration property names in order to keep them in a flatter model on the Razor Server side of things). Also moved the log-file location for the Microkernel Controller to the /var/log directory (to make it consistent with the Razor Microkernel Web Server's logfile location), added additional debugging output, and created a new "Configuration Manager" class (a singleton class that consolidates the common functionality needed in both the WEBrick server and the Microkernel Controller to check for changes in the Microkernel Configuration and save a new configuration to the mk_conf.yaml file). Finally, refactored the names of a number of classes/scripts so that the classes/scripts in the /usr/local/bin directory of the Microkernel all include a "rz_mk_" prefix at the front of their file names.
Commits on Feb 29, 2012
  1. Adding the following licensing text to all of the source-code in the …

    Tom McSweeney committed
    …project:
    
    EMC Confidential Information, protected under EMC Bilateral Non-Disclosure Agreement.
    Copyright © 2012 EMC Corporation, All Rights Reserved
  2. Latest version of the Razor Microkernel (v0.1.4.0); includes changes …

    Tom McSweeney committed
    …to fix the reboot action in the Microkernel Controller, shortening of the sleep interval between iterations (as a carry-over until we can get the push of configuration from Razor working properly), and removal of the "mk" prefix from Microkernel hostname when constructing a uuid for use in checkin/registration. Also added error handling to the main Microkernel Controller loop so that it would continue to run, even in the face of unexpected input from the Razor server (or complete failure of the Razor server). Finally, pulled in some of the files that we modified in the default Tiny Core Linux distribution in order to grab the "next-server" from the DHCP reply (the /etc/init.d/dhcp.sh script and the /usr/share/udhcpc/dhcp_mk_config.script file).
Commits on Feb 27, 2012
  1. @lynxbat
  2. @lynxbat

    first commit

    lynxbat committed
Commits on Feb 26, 2012
  1. Added additional version number information to the README file and cl…

    Tom McSweeney committed
    …eaned up the README file a bit more.
  2. Updating the README file (and breaking out part of it into a separate…

    Tom McSweeney committed
    … README2 file) to reflect the latest changes in this project (currently at v0.1.1.0)
Commits on Feb 25, 2012
  1. Added a command to reboot the node if a "reboot" action is received i…

    Tom McSweeney committed
    …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
    "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
    …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
    … 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
    …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
    …ill complete work on it tomorrow.
  2. Cleaned up how state is handled when the node is registered (now pass…

    Tom McSweeney committed
    …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
    …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
    … 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
    …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
    …of a "neatness counts" sort of checkin
  4. Reworked yesterday's code changes a bit (refactoring names, reworking…

    Tom McSweeney committed
    … 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
    … 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
    …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
Something went wrong with that request. Please try again.