Different computer users interpret light-path diagnostics differently in terms of urgency, however, different hardware vendors implement different light-path schemes that often fail to meet a broad set of customer expectations. What is needed is a policy-driven approach to enable configurable light-path indications, such that a light-path can be in a verbose mode, a quiet mode, or anything in between, in accordance with customer requirements.
Page 1 of 1
User-Configurable Lightpath Policy via Systems Management
In one example, there would exist at least three light-path policies: verbose, quiet, and custom.
Under the verbose light-path policy, any of a set of non-nominal conditions would result in ignition of the light-path.
Under the quiet light-path policy, only critical faults would result in ignition of the light-path.
Under the custom light-path policy, the individual lights that are ignited due to a system condition would be completely configurable.
In the preferred embodiment, a systems management device would be responsible for storing and enforcing the light-path policy. In an alternate embodiment, the ability to switch between policies could be enabled by a button on the front panel.
It is envisioned that users would be able to use Systems Management Software to make light-path policy a part of all system configurations in order to maintain light-path consistency throughout the datacenter, even when hardware is provided by numerous different hardware vendors.
In establishing a completely custom light-path scheme, it is envisioned that light-path could be a part of configuring the alerting scheme of the systems management device. That is, when a user configures alerts to be sent for a particular system condition (such as a LAN alert upon encountering a memory PFA), there can be an additional parameter to indicate whether the user wishes for a light-path indication...
