Redfish message registries, plus translation

[Joseph Reynolds]

On 2/18/20 1:37 PM, Brad Bishop wrote:
>> On Feb 18, 2020, at 2:25 PM, Bills, Jason M <jason.m.bills at linux.intel.com> wrote:
>>
>>
>> On 2/17/2020 5:53 PM, Joseph Reynolds wrote:
>>> On 2/16/20 5:37 PM, Andrew Jeffery wrote:
>>>> On Sat, 15 Feb 2020, at 06:27, Matt Spinler wrote:
>>>>> Hi James,
>>>>>
>>>>> It's looking like in our future we will have to provide:
>>>>>
>>>>> 1) Redfish logs using multiple message registries that probably can't be
>>>>>       hardcoded into hpp files and checked in.
>>>>>       - For example, a registry for our host firmware and hypervisor errors,
>>>>>         as our BMC handles displaying logs for them, that we would pick up
>>>>>         during our build process.
>>>>> and
>>>>>
>>>>> 2) Message registry text in multiple languages
>>>>>
>>>>> Those being my goals, I have a few questions:
>>>>>
>>>>> In general, is the multi-language strategy to just provide a standalone
>>>>> registry array for each language which the code then selects based on the
>>>>> Language property?
>>>>>
>>>>> To support both of the above, would you be open to having functionality
>>>>> added
>>>>> to read in registries from data files, including based on language? Or,
>>>>> would you
>>>>> have any other ideas for how to support these items?
>>>> Bit of a drive-by question, but shouldn't we be using GNU gettext[1] to
>>>> handle translation?
>>> Matt's proposal is for BMCWeb to have two languages:
>>> 1. The implementation language.  When BMCWeb writes internal log entries, these will be in English.  The BMCWeb developers will use these to understand what is going on,  and the BMC admin may be able to read the, but they are not for BMC users.
>>> We can certainly use gettext to internationalize this. But it is not what Matt is asking about.
>>> 2. The languages used for Redfish messages.  These message are added to the HTTP response body.  These are meant to be read by any BMC REST API user.  For example, messages from the Redfish "Base" message registry Base.1.7.0.json within DSP8011.  BMCWeb has a hard-coded version of a subset of these messages, for example, the AccountModified message in https://github.com/openbmc/bmcweb/blob/master/redfish-core/src/error_messages.cpp These messages are defined in English and meant to be translated. That's what Matt is asking about.
>>> Here's my drive-by response.
>>> The current implementation is locked into English-only.  BMCWeb code sends messages like this:
>>> 1. #include https://github.com/openbmc/bmcweb/blob/master/redfish-core/include/error_messages.hpp 2. Write code like: propertyValueModified(res, "myProperty", myModifiedValue);
>>> This calls the function in error_messages.cpp which is hard-coded English.
>>> Having hard-coded function calls and hard-coded implementations helps with BMCWeb's goal for performance and startup times.
>>> https://github.com/openbmc/bmcweb/blob/master/DEVELOPING.md
>>> However, IMHO, the development process to add new Redfish messages to BMCWeb is cumbersome.  It should be as easy as copying Redfish's new JSON file.
>> To ease this, there is a script in bmcweb that is designed to parse the JSON message registries into the header file.
> So I’m a total bmcweb noob - but any reason why the runtime can’t just parse the json?  Why does it have to get converted to a header?

It can.  A few thoughts:

1. As I mentioned above: <quote> Having hard-coded function calls and 
hard-coded implementations helps with BMCWeb's goal for performance and 
startup times. 
https://github.com/openbmc/bmcweb/blob/master/DEVELOPING.md </quote>
Having to read message registries during startup impacts performance.  I 
guess bmcweb startup times would be a tiny bit slower.  Redfish message 
registries are currently 40Kb ... but will grow fatter over time.

2. Having to read message registries during startup time is another 
thing that can go wrong.  An error at build-time, on the BMC's file 
system, or when bmcweb reads the files may prevent BMCWeb from issuing 
meaningful Redfish messages.

3. Presumably one of the hard-coded messages registries would be the 
ultimate fallback message registry, that is, it will be used when the 
required message cannot be found in the message registry for the 
requested language.  Not having a hard-coded message registry removes 
this option.

4. If you are okay with the items above then we can consider a 
build-time BMCWeb config option to build without any built-in message 
registry and rely only on reading message registries from the BMC's file 
system at BMCWeb startup time.  Here are some thoughts:
- The BMCWeb build process could just copy the Redfish message registry 
into a directory BMCWeb reads during startup.
- We would need new code in BMCWeb to read and parse the message 
registries.  The JSON parser is already available within bmcweb.
- We would need new code in BMCWeb to issue messages from the message 
registries.


IMHO, the prospect of removing support for the built-in Redfish "Base" 
message registry seems do-able.  The potential problems and 
disadvantages outlined above seem small.  But I don't have a strong 
opinion either way.

- Joseph