Inventory Grid Service
Table of Contents
Inventory Gridservice
Main purpose of Inventory OMF service is to expose the inventory information to other services as well as experiments (experiment scripts). In addition to obvious node set aliases (say based on device type and ordinal number) it should allow us to query the inventory based on other criteria like "at least 5 nodes with memory > 500M & a bluetooth radio & an Atheros 802.11 card".
- It should have an (optional) query qualifier (with interface to CMC) to return only the functional node set.
- It should have …
Service Configuration File
Lives in /etc/gridservices2/available/inventory.yaml
inventory:
testbed:
default:
# Name of the MySQL Database Server
host: host-name
# Username and password to access the database server
user: the-db-username
password: the-db-password
# Name of the database to use
database: new_new_inventory
Known Device IDs
Devices that are discovered by gathering procedure are uniquely identified by either USB ids or PCI ids. The ids for most important devices are listed below:
| Bus type | Vendor ID | Vendor | Device ID | Description |
| USB | 0x050d (1293) | Belkin | 0x0084 (132) | Bluetooth Transciever F8T003v2 |
| -"- | -"- | -"- | 0x0131 (305) | Bluetooth Transciever with trace filter (F8T001 ?) |
| -"- | 0x0a5c (2652) | Broadcom Corp. | 0x2101 (8449) | A-Link BlueUsbA2 Bluetooth |
| -"- | 0x0a12 (2578) | Cambridge Silicon Radio, Ltd | 0x0001 (1) | Bluetooth Dongle (HCI mode) |
| -"- | 0x0403(1027) | Future Technology Devices International, Ltd | 0x6001 (24577) | ZigBee Mote (FT232 USB-Serial (UART) IC) |
| -"- | 0x04b4 (1204) | Cypress Semiconductor Corp. | 0x8613 (34323) | CY7C68013 EZ-USB FX2 USB 2.0 Development Kit |
| -"- | 0xfffe (65534) | -"- | 0x0002 (2) | CY7C68013 EZ-USB FX2 USB 2.0 (USRP and NoiseGenerator) unprogrammed |
| PCI | 0x11ab (4523) | Marvell Semiconductor | 0x4320 (17184) | 88E8055 Marvell Yukon PCI E Gigabit Ethernet Controller |
| -"- | 0x8086 (32902) | Intel Corp. | 0x4223 (16931) | Intel PRO/Wireless 2915ABG Network Connectio |
| -"- | 0x168c (5772) | Atheros Communications | 0x0013 (19) | Atheros AR5212, AR5213 802.11a/b/g Wireless Adapter |
Inventory Database
The Inventory database is a Mysql database on internal1. The schema was created to be general and scalable, so that it can support many different kinds of nodes and attached devices, and can hold inventory data for multiple testbeds. In general names of tables are plural nouns. When rows in a particular table represent physical objects or concrete ideas, as opposed to relationships or metadata, each row in a table will have a unique id. When an id is referenced from another table, the name of the referencing column will end in _id. Although it is not set in stone, the schema for the inventory database should not change significantly without advance notice on orbit-dev. No data consistency constraints other than automatic ID number generation are implemented in the DBMS, only in the application code. This keeps things flexible enough so that there are lots of options when you find 400 nodes can't all successfully lock tables and rows in the database at once.
It is important to consider the Inventory database schema part of the experimental interface. The advantage of building a web service for Inventory is that it can provide commonly used queries that incorporate data from other OMF web services (namely the CMC, as in "available" in "give me all available intel nodes"). At the same time, it will be easier for experiment scripts to build custom SQL queries that implement complex criteria than to utilize a more abstract web service. Furthermore, arguably, SQL is RESTful in the first place.
The database is used both as the authoritative source of data for the OMF inventory service, and for maintenance purposes. Most of the data is maintained automatically, but some data (such as chassis ID number) can not be collected automatically and must be entered by hand.
These schemas are still changing, so assume the actual database is more authoritative than this document.
Inventory Gathering
Inventory gathering is done as any other ORBIT experiment. It uses a relatively large image, which includes a thorough set of drivers for a wide variety of devices. A new node undergoes an Enrollment process when it is first deployed, implemented as a small PXE image with just enough of a payload to associate the node location with an IP address and report it. In contrast, the Inventory process does the slower more complex job of generating informative scans of the pci and usb busses.
As of 10/16/2007, we run the inventory every Wednesday during maintenance. We may also run it when there are significant hardware changes.
The gathering procedure uses lspci, lsusb, dmidecode and sysfs. The most frustrating and difficult part of maintaining the code is keeping up with changes in /sys over even minor kernel revisions.
The current inventory code can all be found in the image inventory.ndz in /root/inv.tar. Source is controlled by git. At the time of this writing there is no functioning git server at WINLAB, so just mail patches to jfm3 at winlab.rutgers.edu. From baseline.ndz, you will also need the packages sbcl, cl-sql, and cl-ppcre. Porting to a new baseline image is usually a fair amount of work. sysfs has proven to be a very moving target, so far.
To run inventory, follow the following procedure from the console. (It would be good to script more of this.)
sh> tar xvf inv.tarsh> mkdir -p ~/.sbcl/systemssh> cd inventorysh> ln -s *.asd ~/.sbcl/systems
You only need to do the above steps once ever. If you use symbolic links, untarring new versions of the code over the old will not cause any problems downstream.
sh> sbclsbcl> (asdf:operate 'asdf:load-op 'inventory)sbcl> (inv:open-inventory)sbcl> (quit)sh> orbit load all inventory.ndzsh> orbit exec invsh> sbclsbcl> (asdf:operate 'asdf:load-op 'inventory)sbcl> (inv:regenerate-tags-table)sbcl> (inv:close-inventory)sbcl> (quit)
