ROCKS Node Info

A feature that is weak or missing from ROCKS is a way to add user defined parameters on a per node basis. There is a mechanism for adding user defined site parameters (App_Globals), and there is the set of ROCKS defined node parameters (rack, rank, ip, etc.). It would be possible to add a new table to the MySQL database to hold this info, but (for now at least) a "simpler" hack will do. Note that the ROCKS developers don't recommend changing their database schema.

The plan is to maintain a spreadsheet with one row per node and columns that define various parameters. This spreadsheet will be saved as a csv file and the file accessed using a python module. Scripts can then be created that use this module to return node info. In the future, the data store (csv file) could be replaced with another implementation (perhaps a python pickle file or a real database). However, using the csv file is expected to provide enough performance for a reasonable number of nodes (hundreds) and number of parameters (tens). The python module will only do look-up (read-only) access to the csv file.

Putting vars into ROCKS install

Want to be able to use these variables and values in ROCKS xml files. It isn't clear how to do this in a "global" way. Simpler for now is to just use an eval in the node xml file as needed.

Env Vars

There are two main execution environments, on the frontend during kickstart file generation and in the installer on the node.

Attached is the output of printenv run in an eval block in an .xml file (i.e. on the frontend). Note that not all of these are defined by ROCKS an available using the <var> tag.

There are multiple places in ROCKS that have code for generating the kickstart file. Some of these seem to be legacy from older versions, /opt/rocks/sbin/kpp for instance. The command "rocks list host xml [host]" seems to be the current starting point. Haven't determined just how the variables that can be accessed using <var> are filled from the database. But this doesn't seem like a mechanism that can or should be extended...

node-info

-- TomRockwell - 19 May 2008

• printenv-frontend.txt: output from printenv run during kickstart generation on frontend. This was done from within an xml file (forget exactly how now...). Note that these same vars are available in a script run from an <eval> as a subprocess is used.