|
Post by dhruvaraj on Feb 8, 2021 19:06:49 GMT
We are looking for a method to manually disable processor core and memory DIMM. This is a functionality provided on IBM systems to mark a processor or DIMM as disabled to keep those manually out of service during the subsequent boots. One option is making the Status:state(http://redfish.dmtf.org/schemas/v1/Resource.json#/definitions/Status) as writable. OpenBMC design for this feature can be found at: gerrit.openbmc-project.xyz/c/openbmc/docs/+/27804
|
|
|
Post by mraineri on Feb 8, 2021 19:27:32 GMT
Due to the common nature of the Status object, the intent is to keep it and all of its properties as read-only; making anything in the object writable would have pretty drastic ramifications in the rest of the data model.
Usually the pattern we have in other resources is we create specific control properties to manage things like enabled/disable, such as the "ServiceEnabled" property in AccountService. I would recommend if we add support for this type of control in processors and memory, the same pattern should be followed.
|
|
|
Post by dhruvaraj on Feb 10, 2021 12:32:41 GMT
Thanks, mraineri "ServiceEnabled" Looks like a good fit for this purpose, If the "ServiceEnabled" is set to 'false' that DIMM or Processor can be disabled in the next boot. But the "ServiceEnabled" is not present in the DIMM or Processor schema, so how to get added that?
|
|
|
Post by jautor on Feb 11, 2021 1:54:04 GMT
Thanks, mraineri "ServiceEnabled" Looks like a good fit for this purpose, If the "ServiceEnabled" is set to 'false' that DIMM or Processor can be disabled in the next boot. But the "ServiceEnabled" is not present in the DIMM or Processor schema, so how to get added that?
After discussion this is something that is likely supported by implementations today, through BIOS setting or other non-standard methods, so adding a standard property to Processor and Memory (DIMM) schemas is a good idea. We'll likely just call this "Enabled" as we do use that very general term elsewhere, too.
I would expect this to be approved for the next release of the Redfish schema.
Thanks for the input!
Jeff
|
|
|
Post by dhruvaraj on Feb 12, 2021 7:51:21 GMT
Thank you, it is needed on the Processor core, which is modeled as subprocessor, /redfish/v1/Systems/{ComputerSystemId}/Processors/{ProcessorId}/SubProcessors/{ProcessorId2}
|
|
|
Post by jautor on Feb 13, 2021 3:47:29 GMT
Thank you, it is needed on the Processor core, which is modeled as subprocessor, /redfish/v1/Systems/{ComputerSystemId}/Processors/{ProcessorId}/SubProcessors/{ProcessorId2} Understood - we'd add it to the Processor schema, which will cover both the "Processors" collection and the "SubProcessors" as they share the same schema definition. Jeff
|
|
|
Post by AMI_Mani on Feb 16, 2021 18:14:38 GMT
Can we consider adding Enabled attribute for PCIeFunction also ? We can also consider an action like changestate which can be used to change state to disabled for Processor, DIMM, PCIeFunction
Thanks, Mani
|
|
|
Post by jautor on Feb 18, 2021 17:11:07 GMT
Can we consider adding Enabled attribute for PCIeFunction also ? We can also consider an action like changestate which can be used to change state to disabled for Processor, DIMM, PCIeFunction Thanks, Mani
I'll bring that up, as disabling a PCIe Function is probably just as common a use case as processor or DIMM. I think we'll just create a R/W property rather than an Action as this is easily described with normal REST semantics.
Jeff
|
|