FRU Concurrent Maintenance | Redfish Specification Forum

puranik
Minnow

Posts: 8

FRU Concurrent Maintenance Sept 30, 2020 14:42:36 GMT

Quote

Post by puranik on Sept 30, 2020 14:42:36 GMT

Hi,

On IBM systems managed by OpenBMC, we have a requirement for performing Field Replaceable Unit (FRU) Concurrent Maintenance (CM).

CM indicates the ability to add, replace or remove a FRU without bringing the workload down or even powering down the system.

This is an operation that can be triggered out-of-band and involves the following (high-level) steps:

User selects the FRU to CM. The operation could be add, replace or remove.
In case of remove/replace operations, the BMC needs to perform necessary background handshakes with the hypervisor/other host firmware (to have it stop using that FRU). Once that is done, the user has to physically remove the FRU.
If the operation was remove we are done here. If the operation is to add/replace, the user plugs in the new FRU and the BMC has to work with the host firmware to (re)integrate the FRU into the system..

Is there an API that Redfish recommends to perform an operation such as this?

We took a cursory look at the schema and were thinking of using a combination of the ReadyToRemove (https://redfish.dmtf.org/schemas/v1/Drive.v1_11_0.json) and State (http://redfish.dmtf.org/schemas/v1/Resource.json#/definitions/State) properties to trigger and monitor the state of this operation. So the flow would be something like:

User sets ReadyToRemove to true in order to initiate the CM operation. The BMC can react to this and do what is needed to "remove" the FRU from the system. State property can be used to monitor the progress of this operation.

When the State goes to "StandbyOffline" (for example), the remove operation can be deemed complete.

When the new FRU is plugged in, setting ReadyToRemove to false should trigger the BMC to perform an "add" and change the State to something meaningful to indicate completion.

Does this sound like a good way to fit in the CM use case? If so, would it make sense to add the "ReadyToRemove" property to the Assembly (as a part of the AssemblyData property) and PCIeDevice schemas (our current use case for CM only covers FRUs that we plan to represent within these schemas)?

Thanks,

Santosh

jautor
Administrator

Posts: 502

FRU Concurrent Maintenance Sept 30, 2020 16:15:24 GMT puranik likes this

Quote

Post by jautor on Sept 30, 2020 16:15:24 GMT

Santosh,

This is a good topic and one that the group should consider. As the ReadytoRemove is currently only defined in Drive, and this concept will apply to many resources, I wonder if we should define either a new property, an Action, or perhaps yet another enumeration for the Reset action to "prepare the device for hot plug removal". I need to check to see if the ReadyToRemove property was intended (and implemented) to actually "do something" or if it was just intended for a user to indicate that state (e.g. light an LED). The normative language doesn't give any guidance there.

We have the Quiesced value for State defined, that would be the one I would suggest using to represent the "ready to remove" state.

I'll have to look at how we'd do this for something in Assembly - do you have FRUs that would need this support that aren't represented by a device-level resource in Redfish (or an OEM-defined resource)? Note that we have a work-in-progress published that shows proposed resources for individual fans and power supplies.

I will bring this up as a topic to the group!

Jeff

puranik
Minnow

Posts: 8

FRU Concurrent Maintenance Sept 30, 2020 17:23:21 GMT

Quote

Post by puranik on Sept 30, 2020 17:23:21 GMT

Hi Jeff,

Thanks for your response.

I need to check to see if the ReadyToRemove property was intended (and implemented) to actually "do something" or if it was just intended for a user to indicate that state (e.g. light an LED). The normative language doesn't give any guidance there.

I kind of assumed it was intended to take an action because it was marked ReadWrite. Do you feel that an Action would fit in better here as opposed to a property?

We have the Quiesced value for State defined, that would be the one I would suggest using to represent the "ready to remove" state.

+1, Quiesced makes sense.

I'll have to look at how we'd do this for something in Assembly - do you have FRUs that would need this support that aren't represented by a device-level resource in Redfish (or an OEM-defined resource)? Note that we have a work-in-progress published that shows proposed resources for individual fans and power supplies.

Yes, there are FRUs such as the Operator Panel, RTC Batteries (which we chose to model as Assemblies per the discussion here: redfishforum.com/thread/325/fru-properties-redfish). These are concurrently maintainable on our systems. Having this property (or action, if we go that route) on Fans and Power supplies would help too!

I will bring this up as a topic to the group!

Thanks!

Santosh