Sorry for the late posting of those minutes (I thought I sent that the day after the meeting but cannot find any trace of it so if this is a duplicate please ignore it). Attendees: Mary Meredith, OSDL George Mann, Individual contributor Renier Morales, IBM Randall Loomis, Wind River Tariq Shureih, Intel Martine Silbermann, HP The meeting was called to address the question of how will OpenHPI be able to handle control versus monitoring, or is that even the intent of OpenHPI? OpenHPI implements the HPI spec that allows for control as well as monitoring. OpenHPI supports control when there is a plug-in that handles the control. HPI just means Hardware Platform Interface, and that interface in general terms lets you monitor and control hardware. Reading sensors, inventory type data reading (serial numbers, versions of firmware). There is a set of hotswap api calls you can use to manage when FRU are being inserted/removed and to handle other actions related to that. Spec gives much more information. OpenHPI is just an open source implementation of the spec. Over 70 API calls are implemented as a library. They provide support for reading sensors, thresholds, etc... Watchdogs can be used as part of the control. Further details can be found at the SAF Forum web site www.saforum.org Question: If a sensor displays a reading outside the allowed threshold range (for ex. temp too high) can open hpi make the decision of isolating the device? OpenHPI itself doesn't make that kind of decision, it's the APIs above it that would have to include the logic required to make that decision. You make direct calls to the library: discovery, what resources are available on the system? OpenHPI probes the system. Depending on the data you get back for each sensor you can look up the corresponding threshold level. It's the logic above OpenHPI that makes the decision to isolate or shutdown. on the logic. IPMI uses an event based protocol, HPI monitors those events. It will generate an event to the management controller which in turn will handle them. Open HPI gives you ability to do something to respond to the events: power cycle, remove, ... Blades are covered, there's no specific architecture limitation. HPI is not tied to a specific platform. OpenHPI is a userspace shared library, that has a binary interface. Developers interested in making it work on specific platforms have to write hardware enabling modules. Those modules mostly run at the user level but sometimes need to run at kernel level. SNMP: issuing calls over the network to talk to the management controller on the blade center. Inconsistency in terminology: You as talking about hotplug not hotswap. Hotswap in the OpenHPI context comes from the telecom side, in DCL case hotswap/cpu. The way the resources are modeled, is slightly different. USB devices which are hotplug-able are not on the OpenHPI radar. Question: Can HPI spec address HBA? OpenHPI should be able to addressing it. Question: Does OpenHPI support an interface for SMART storage systems? This is under consideration. They would need a plug-in to do the hotplug control parts. Is this in the list of needed features on the wiki? if yes for what release? Question: How do you access ACPI data through OpenHPI? Len Brown, maintainer of ACPI, split between proc and sysfs, acpi has its own challenges... haven't pursued until they decide how to merge. There was some sysfs support (plug-in to sparse sysfs and extract info from the files) but it hasn't been used in a while and might be out of date possibly. Depending on what cpu hotplug exposes via sysfs, should be able to access that with minor mods. OpenHPI is the only open source implementation of the HPI spec but there are a few commercial uses of the spec. For example Augmentix distributes the Augmentix A+HPI(tm) platform management software package which is a proprietary implementation of HPI. Also GoAhead's SelfReliant's systems management capabilities using OpenHPI as their interface to the hardware layer. The SAF Forum a consortium of industry-leading communications and computing companies (tend to concentrate more on TELCO systems). Question: Openhpi is supported on all SLES9 architectures: when you want to know what platforms are supported, that means that openhpi builds on all these architectures but not necessarily that it runs on them. Current plug-ins are for SNMP Blade Center (runs optimally on IBM Blade center Telco and IBM Blade Center Enterprise but should support all SNMP) and IPMI (runs optimally on Intels rack mount advanced servers but should be able to support any IPMI at about 90% SUN, HP, Dell, RadiSys, anything with an IPMI management controller, any X-series hardware (product for IBM blade center) IPMI plug-ins have OpenHPI dependencies, for more details look at wiki.openhpi.org or ask on the openhpi mailing list. Question: Difference between simplify hotswap state model and fully managed hotswap state model? Simplified state model (supported by SNMP Blade Center) only gives you 2 states: active or inactive where the fully managed hotswap state model (supported by IPMI) has different states such a insertion pending, extraction pending,...(see spec for more details). Each blade is a small server but the whole blade can be set up as the FRU. IPMI overlaps some of HPI, but HPI is definitely at a higher level, wrapper to IPMI. Other open source management tools: Open Pegasus is an open-source implementation of the DMTF CIM and WBEM standards. Currently ongoing in cvs , release 2.4 provides a Linux implementation. Client to WEBM talks to a CIM provider, would make calls via HPI to hotswap a cpu, HPI needs a plug-in to handle the event. Vendor supplies the CIM agent. Forum that defines the WBEM: DMTF (financial industry mostly, customer driven) is to WEBM, as the SA forum is to HPI. Here are some useful web sites for info on OpenHPI and system management: http://wiki.openhpi.org/ http://openhpi.sourceforge.net/ http://www.saforum.org/home http://www.dmtf.org/home --
