Much like the reporting issue, this is an aspirational concept being documented for "some time down the road."
We have enough data in this zenpack alone to trip ledctl a la ledctl locate=/dev/sdX so long as we can isolate the path alone (without the added smartctl command params).
Zenoss has the ability to run commands in response to triggers, and given that we have the relevant information to SSH into a host using Twisted, we can pass that information to the script as variables in order to execute commands via scripted-ssh-interaction - those being ledctl locate= and ledctl locate_off= when we clear/close the appropriate alert.
Providing an example command and trigger like some of the sk1lls1st packs had back in the day would permit users to rapidly configure full-fledged disk monitoring and remedial response (in terms of remote hands knowing which drive to pull). Since the scripts can be modified, they could insert their own dismounts, logical and physical block device spin-downs, etc per their environmental needs along with the ledctl calls.
ledctl isn't universally effective, the interfaces aren't as well standardized and implemented across different kernels/userspaces/etc. However, when dealing with datacenter-scale workloads, on enterprise hardware which is more or less functional in this regard, it can be a huge time saver and risk-reduction function (remote hands may be careful, but not as careful as the system owners - this would add kid-gloves).
Much like the reporting issue, this is an aspirational concept being documented for "some time down the road." We have enough data in this zenpack alone to trip
ledctla laledctl locate=/dev/sdXso long as we can isolate the path alone (without the addedsmartctlcommand params). Zenoss has the ability to run commands in response to triggers, and given that we have the relevant information to SSH into a host using Twisted, we can pass that information to the script as variables in order to execute commands via scripted-ssh-interaction - those beingledctl locate=andledctl locate_off=when we clear/close the appropriate alert. Providing an example command and trigger like some of the sk1lls1st packs had back in the day would permit users to rapidly configure full-fledged disk monitoring and remedial response (in terms of remote hands knowing which drive to pull). Since the scripts can be modified, they could insert their own dismounts, logical and physical block device spin-downs, etc per their environmental needs along with theledctlcalls.ledctlisn't universally effective, the interfaces aren't as well standardized and implemented across different kernels/userspaces/etc. However, when dealing with datacenter-scale workloads, on enterprise hardware which is more or less functional in this regard, it can be a huge time saver and risk-reduction function (remote hands may be careful, but not as careful as the system owners - this would add kid-gloves).