|
|
Post by manojkiran on Mar 10, 2021 9:40:29 GMT
In openbmc , we have added many openbmc message registries as mentioned in this link :
Sample example :
{
"Copyright 2018 OpenBMC. All rights reserved.",
"#MessageRegistry.v1_4_0.MessageRegistry",
"OpenBMC.0.1.0",
"OpenBMC Message Registry",
"en",
"This registry defines the base messages for OpenBMC.",
"OpenBMC",
"0.1.0",
"OpenBMC",
}
MessageEntry{"BIOSPOSTCode",
{
"BIOS Power-On Self-Test Code received",
"Boot Count: %1: TS Offset: %2; POST Code: %3",
"OK",
"OK",
3,
{"number", "number", "number"},
"None.",
}}
Now, we wanted to add a new argument in the existing Message Entry for example :
MessageEntry{"BIOSPOSTCode",
{
"BIOS Power-On Self-Test Code received",
"Boot Count: %1: TS Offset: %2; POST Code: %3"; POST Code in Ascii : %4,
"OK",
"OK",
4,
{"number", "number", "number","string"},
"None.",
}}
How do we improve the existing message registry like above and also have the backward compatibility ?
|
|
|
|
Post by jautor on Mar 10, 2021 15:10:14 GMT
You can't add arguments to an existing message, as that will break client software (they can receive too many or too few arguments).
The correct way to handle this is to add a new message with a similar name, like "BIOSPOSTCodeASCII", with the new argument set. And then bump the minor version of your Message Registry as new messages have been defined.
Jeff
|
|
|
|
Post by manojkiran on Mar 11, 2021 8:46:22 GMT
You can't add arguments to an existing message, as that will break client software (they can receive too many or too few arguments). The correct way to handle this is to add a new message with a similar name, like "BIOSPOSTCodeASCII", with the new argument set. And then bump the minor version of your Message Registry as new messages have been defined. Jeff Thanks Jeff. |
|
|
|
Post by manojkiran on Mar 20, 2021 1:49:34 GMT
Jeff,
How does a redfish client who is using the "BIOSPOSTCode" work after we bump the message registry ?
|
|
|
|
Post by jautor on Mar 22, 2021 3:37:53 GMT
Jeff, How does a redfish client who is using the "BIOSPOSTCode" work after we bump the message registry ?
The definition for "BIOSPOSTCode" would remain unchanged from the previous version. You would add the new message (hence the version change of the registry), but the previous messages are still included and are still valid. Existing clients would understand "BIOSPOSTCode", but would not recognize the new message, but would identify that condition by detecting the registry version that is higher than it supports.
So it doesn't remove the need to add new support to clients for them to understand the new message, but the existing message is unaltered so code that was aware of that message doesn't break...
Jeff
|
|
|
|
Post by manojkiran on Mar 22, 2021 15:54:18 GMT
Jeff, How does a redfish client who is using the "BIOSPOSTCode" work after we bump the message registry ?
The definition for "BIOSPOSTCode" would remain unchanged from the previous version. You would add the new message (hence the version change of the registry), but the previous messages are still included and are still valid. Existing clients would understand "BIOSPOSTCode", but would not recognize the new message, but would identify that condition by detecting the registry version that is higher than it supports.
So it doesn't remove the need to add new support to clients for them to understand the new message, but the existing message is unaltered so code that was aware of that message doesn't break...
Jeff
But, we changed the Message registry that we are sending to the client.I am confused, Apologies for asking again, can you explain a bit more on how a standard redfish client should parse ? based on the below example ?
Say for example, client is now parsing the below GET response from the redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1 URI. Note that we are sending "MessageId": "OpenBMC.0.1.BIOSPOSTCode", which just have 3 arguments as shown below.
curl -k -H "X-Auth-Token:$bmc_tokens" -X GET https://127.0.0.1:3443/redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1
{
"@odata.id": "/redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1",
"@odata.type": "#LogEntry.v1_4_0.LogEntry",
"Created": "2021-03-04T06:29:35+00:00",
"EntryType": "Event",
"Id": "B1-1",
"Message": "Boot Count: 1: TS Offset: 56.4424; POST Code: 0x205942444e415453",
"MessageArgs": [
"1",
"56.4424",
"0x205942444e415453"
],
"MessageId": "OpenBMC.0.1.BIOSPOSTCode",
"Name": "POST Code Log Entry",
"Severity": "OK"
}
Now, if i get what you are saying, we have added a new registry and bumped the version to 0.2 so that output of GET will look like below, Note that "MessageId": "OpenBMC.0.2.BIOSPOSTCodeASCII", which has 4 arguments.
curl -k -H "X-Auth-Token:$bmc_tokens" -X GET https://127.0.0.1:3443/redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1
{
"@odata.id": "/redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1",
"@odata.type": "#LogEntry.v1_4_0.LogEntry",
"Created": "2021-03-04T06:29:35+00:00",
"EntryType": "Event",
"Id": "B1-1",
"Message": "Boot Count: 1: TS Offset: 56.4424; POST Code: 0x205942444e415453; POST Code in Ascii: STANDBY ",
"MessageArgs": [
"1",
"56.4424",
"0x205942444e415453",
"STANDBY "
],
"MessageId": "OpenBMC.0.2.BIOSPOSTCodeASCII",
"Name": "POST Code Log Entry",
"Severity": "OK"
}
Now , my question is a client which is already expecting : 1. 0.1 version number gets version 0.2 2. OpenBMC.0.1.BIOSPOSTCode gets OpenBMC.0.2.BIOSPOSTCodeASCII 3. 3 arguments but now gets 4 arguments.
How does redfish makes sure that the clients that are checking /redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1 & are coded for OpenBMC.0.1.BIOSPOSTCode are NOT broken ?
|
|
|
|
Post by jautor on Mar 23, 2021 23:31:46 GMT
Now , my question is a client which is already expecting : 1. 0.1 version number gets version 0.2 2. OpenBMC.0.1.BIOSPOSTCode gets OpenBMC.0.2.BIOSPOSTCodeASCII 3. 3 arguments but now gets 4 arguments.
How does redfish makes sure that the clients that are checking /redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1 & are coded for OpenBMC.0.1.BIOSPOSTCode are NOT broken ?
You've defined a new message, so an existing (old) client won't know how to decode that. Nothing we can do about that. But the client will know that - because it's a MessageId that is unknown to the client (and from a version of the registry higher than it supports). So the client can report "unknown message BIOSPOSTCodeASCII" (probably display the arguments received). And if the "Message" property is included, it can always just display that even if it can't fully decode or translate the message. The reverse is what we are protecting against with backward compatibility. If you updated your client to understand a 4-argument version of a message previously define with only 3, an old service sending that 3-argument message might cause a "out of range" fault or crash... Hope that makes sense, Jeff |
|
