In the general HardwareManager class there exists some methods which seem to only work in the manner in which they are implemented in GenericHardwareManager while appearing to be abstract methods which could be implemented by custom hardware managers. If one were to attempt to implement one of these methods, the results would likely be unexpected. Therefore, it may be best to simply remove them from HardwareManager, or to move their implementation from GenericHardwareManager to HardwareManager.
In particular, it seems that these are list_block_devices, get_skip_list_from_node, and list_block_devices_check_skip_list. These all currently only raise IncompatibleHardwareMethodError. The purspose of IncompatibleHardwareMethodError is used when running dispatch_to_managers to allow it to move on to the next manager. However, as implemented, none of them are called with dispatch_to_managers and none of the calls handle the IncompatibleHardwareMethodError. This means that if they were implemented inside of a custom hardware manager and if they were to throw IncompatibleHardwareMethodError as does the abstract method, then rather than skipping that particular check and passing it on to the next manager, instead it would cause the calling method to throw IncompatibleHardwareMethodError forcing it to be rejected. This would seem to be unexpected behavior.
If these methods were instead had only their full implementations, either as part of HardwareManager or GenericHardwareManager, but never presented as abstract methods, it seems that this would mitigate this problem so that developers of custom hardware managers would not presume that they could simply create their own implementations without consequences.
