[DISCUSSION] Drive-level power control support in phosphor-state-manager

[Eric Yang]

Hi all,

I've been looking into how OpenBMC currently handles component-level
power control for storage drives, and would appreciate some input on
possible directions.

On storage servers or compute servers with NVMe/SSD drive bays, there
is a practical need to monitor drive power state and perform controlled
power cycling or reset of individual drives.

The State.Drive interface added in change 43155 [1] defines
RequestedDriveTransition and CurrentDriveState, but I could not find
any upstream consumer for the transition/state properties. Please
correct me if I'm missing an existing implementation.

If a platform wanted to support drive power control through
phosphor-state-manager today, the options would be:
- Map drives as additional chassis/host instances, which carries
  incorrect semantics and breaks the Redfish model.
- Write a platform-specific daemon outside of the state-manager
  framework.

phosphor-state-manager already has a well-established per-instance
daemon pattern with systemd target orchestration. Following this
pattern for drives seems like a natural fit.

I'd appreciate any thoughts on the following:
- Is there interest in drive power control as a first-class feature
  in phosphor-state-manager?
- Should it follow the existing host/chassis daemon pattern, or
  should it be designed as a more generic component state manager
  that could cover other device types in the future?
- Drive instances may benefit from string identifiers (e.g. nvme0)
  instead of numeric IDs to align with Redfish DriveId. Any concerns
  with this approach?
- Should a drive's power state optionally be tied to a specific
  host's power state (e.g. power off drives when the associated
  host shuts down), or should drive power be fully independent?

[1] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/43155

Best Regards,
Eric Yang