Changes between Version 45 and Version 46 of Internal/InventoryV3


Ignore:
Timestamp:
Jan 10, 2013, 9:50:32 PM (12 years ago)
Author:
ssugrim
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/InventoryV3

    v45 v46  
    11James is working on a second generation inventory script.
    22
    3 Currently on: Restructuring writer and correcting table assumptions
     3Currently on: Rest Integration for new database type and Cpu Bench marks
    44
    55Versions:
    66
    7  * gather.rb:2.30
    8  * inventoryNode.rb: (Written by Ivan, Live in the /root directory of the respective console).
    9 
    10 It's plan is to be simpler and less ambitious than it's predecessor, but still respect the sql table structure ("as much as possible.")
    11 
    12 There are 4 parts to this process:
    13  1. inventoryv2.rb: execs scripts on nodes using orbit framework
    14  1. gatherer.rb: collects information using only  operating system based facilities (dmesg, lsusb, lspci, ifconfig, /sys, lshw). 
    15  1. writer.rb: checks the mysql repository for changes from the current state. If different changes them.
    16  1. logcopy.rb: check the log file for errors, if present copies the Logs to a specfied location
    17 
    18 
    19 The sql structure is a bit of a bit mess, the major tables of interest are:
    20  1. motherboards - List of things that can be connected to, has its own id used to tie other tables to it
    21  1. devices - List of deviced "connected" to mother boards
    22  1. device_kinds - type identifier for connected devices (an attribute of a device).
    23  1. locations - Converts x,y,testbed_id coordinates to a single integer
    24  1. nodes - maps motherboard to locations, also has an id for said mapping
    25  1. inventories - records the start and stop time of the inventory pass.
    26  1. testbeds - gives a testbed id for the specific domain, thus disambiguating node1-1
    27 
    28 A lot of the tables are full of unused colums. I guess we'll just ignore them for now.
    29 The basic crux of an update should be the following:
    30  1. examine our IP (and hostname) to determine our current location
    31  1. We gather information about the mother board:
    32  1. '''Gatherer:'''
    33   1. Disk Size (dmesg)
    34   1. Memory Size (dmesg)
    35   1. Cpu number (dmesg)
    36   1. motherboard serial number (lshw)
    37   1. Gather information about attached devices:
    38    1. 2 wired Ethernet addresses (ifconfig, /sys)
    39    1. 2 wireless Ethernet addresses (ifconfig, /sys)
    40    1. any usb devices (lsusb, /sys)
    41   1. export to xml
    42  1. '''Writer:'''
    43   1. import xml output from gatherer
    44   1. collect identifiers from mysql based on gathered infromation (domain => testbed_id ;x,y,testbed_id => loc_id;
    45      mb_ser => mb_id ; loc_id => node_id ; )
    46   1. update mother board information if different, and stamp with current inventory number
    47   1. add kinds if they don't exist already
    48   1. update devices if diffrent and stamp with inventory number
    49   1. update node mb_id if loc, mb pair don't match
    50  1. profit.
    51 
     7 * gather.rb:3.5
     8 * rest_db.rb:1.3
     9 * log_wrap.rb:0.1
     10
     11
     12It's plan is to be simpler and less ambitious than it's predecessor. Instead of the old sql, we'll now use the new rest client.
     13
     14There are 3 parts to this process:
     15
     16 1. gatherer.rb: collects information using operating system based facilities and tools(dmesg, lsusb, lspci, ifconfig, /sys, lshw, sysbench). 
     17 1. rest_db.rb: a generic rest-client wrapper library for interfacing the rest based database with and it's flat data structure
     18 1. log_wrap.rb: a unified log class that can be share across many distributed ruby files.
     19
     20
     21The Rest Data base structure is a flat resource / attribute mode. Nodes and their "attached" devices are consiered resouces. The devices attached to a node are children resouces of the node. Both nodes and their devices will have meaning full attributes. Attributes come in 3 heading types INV, CM, INF. Those are described here. gathering is only concerned with INV type attributed: This is what is colleted and how they are related
     22 1. Nodes
     23  1. INV_hd_sn
     24  1. INV_mb_sn
     25  1. INV_cpu_bench
     26  1. INV_memory
     27  1. INV_cpu_hz
     28  1. INV_cpu_type
     29  1. INV_hd_size
     30  1. INV_check_in
     31 1. Devices
     32  1. INV_dev_id
     33  1. INV_dev_type
     34  1. INV_if_name (optional)
     35  1. INV_if_mac (optional)
    5236----
    5337== Require Tools / Libraries ==
    5438
    55  1. lsusb (usbutils.deb)
    56  1. lspci (native)
    57  1. dmesg (native)
    58  1. ifconfig (native)
    59  1. libxml-simple-ruby.deb
    60  1. libmysql-ruby.deb
    61  1. lshw (lshw.deb)
    62  1. logger (ruby standard)
     39=== Ubuntu Standard ===
     40 1. date
     41 1. hostname
     42 1. lsusb
     43 1. lspci
     44 1. dmesg
     45 1. ifconfig
     46 1. lshw
     47
     48=== apt-pacakge ===
     49 1. librestclient-ruby
     50 1. sysbench
     51
     52=== ruby standard ===
     53 1. logger
    6354 1. ftools (ruby standard)
    6455
    6556----
    6657Gatherer:
    67 The disk size and memory size are a quick scan from dmesg. The disk size matches, but the memory size is a little off. It probably has to do with the way dmesg reports memory vs /sys reports memeory. It would be nice to find the /sys entry for consistency.
    68 
    69 In /sys/devices/pci0000:00 are the sub directories correlated with the specific Ethernet hardware. In each directory that correlated to an Ethernet device there will be a symbolic link with the operating system name of the device. This will allow us to match up the pci address(name of the subdirectory of /sys/devices/pci0000:00) to the mac address (from ifconfig). lspci can tell us the associated pci address and a hardware identifier string.
    70 
    71 lsusb on the otherhand offers a direct correlation to the device kind table, the ordered pair of numbers xxxx:yyyy directly correlated to the tables vendor and device ids.  And the Bus xxx Device yyy number fits into the addres category of the device table.
     58
     59Gatherer is now the only executable. It preforms both gathering and updating (via the rest client). It's collects information mostly via regular expressions on the output of the various tools and uses them to identify the node (by it's fqdn), and populate the data paramters.
     60
     61----
     62
     63= NOTES =
    7264
    7365=== 9/29/09 ===
     
    462454I may branch off a threaded version to make it a little faster but that might right into blocking issues with concurrent runs of lshw. Also on the Horizon is the idea of using a full Diskless ubuntu server pxe image to house the inventory process. This should resolve some of the missing info/driver issues.
    463455
     456=== 1/10/2013 ===
     457
     458This project has essentially been completely rewritten from the ground up to accommodate the new data base type described here. Most of the regular expression and tools are the same but the data base interface is completely revamped (separate library). We collect fewer pieces of data, but each piece is more meaningful, and their logical context now easier to ascertain from the db structure. The central identifier is now the fqdn of the node (this establishes it position as well as it's heirarchy), the old "context-less unique identifier" is long gone.
     459
     460To launch the process we now use a start up script instead of the old oml construct. This means the process to run inventory is as simple as:
     461
     462 1. Image nodes with inventory image
     463 2. restart nodes
     464
     465While this method is effective, it has the draw back that each time we update gatherer, a new image has to be created. This is not so big a deal because gatherer updates come so infrequently, that the image usually ends up having to be updated any way. The inventory start up script looks like
     466{{{
     467#!/bin/bash
     468echo "Sleeping 30" > /tmp/inventory.log
     469sleep 30
     470let amt=$RANDOM%10
     471echo "Sleep $amt" >> /tmp/inventory.log
     472sleep $amt
     473echo "NTP info" >> /tmp/inventory.log
     474ntpq --numeric --peers >> /tmp/inventory.log
     475echo "Starting gatherer" >> /tmp/inventory.log
     476ruby -I /root/ /root/gatherer.rb -d  -l /tmp/gatherer.log >> /tmp/inventory.log
     477echo "Done" >> /tmp/inventory.log
     478}}}
     479
     480Add this file to /etc/init.d and then run
     481{{{
     482update-rc.d inventory.sh defaults 99
     483}}}
     484
     485The out put should look like:
     486{{{
     487oot@node1-1:~# update-rc.d inventory.sh defaults 99
     488update-rc.d: warning: /etc/init.d/inventory.sh missing LSB information
     489update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
     490 Adding system startup for /etc/init.d/inventory.sh ...
     491   /etc/rc0.d/K99inventory.sh -> ../init.d/inventory.sh
     492   /etc/rc1.d/K99inventory.sh -> ../init.d/inventory.sh
     493   /etc/rc6.d/K99inventory.sh -> ../init.d/inventory.sh
     494   /etc/rc2.d/S99inventory.sh -> ../init.d/inventory.sh
     495   /etc/rc3.d/S99inventory.sh -> ../init.d/inventory.sh
     496   /etc/rc4.d/S99inventory.sh -> ../init.d/inventory.sh
     497   /etc/rc5.d/S99inventory.sh -> ../init.d/inventory.sh
     498}}}
     499
     500Note: For full enumeration of all devices on a baseline image, make sure you remove the modprobe blacklists. If you don't the wifi modules won't get enumerated and the gathering won't find them.