Inventory Grid Service

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. 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.