Message registries continuation

[Matt Spinler]

Hi James,

Something I forgot below - when building up our event logs, I have about 
a dozen fields (mostly OEM)
that I have to get from the OpenBMC event log's corresponding PEL (IBM's 
enterprise log format).

PELs aren't on D-Bus for a few reasons, such as they can be several KB 
in size and consist of several
dozen discrete fields, so that rules out bmcweb getting them that way.

I do have a shared library that has the PEL APIs I need (PELs themselves 
are in files). Is it OK if I
just link in that library as needed when a USE_PELs or whatever option 
is set?
Alternatively, I could also dlopen it I suppose.

Just trying to avoid a surprise during review.

Thanks

On 6/16/2020 3:39 PM, James Feist wrote:
> On 6/16/2020 12:47 PM, Matt Spinler wrote:
>> Hi James,
>>
>> Picking up the discussion again from 
>> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020620.html
>> about reading  in message registries...
>>
>> When this was left off, I believe we were leaning toward being able 
>> to copy message registry JSON files
>> into some target directory on the BMC during the build where bmcweb 
>> would load them on startup
>> and leave them in their JSON objects, and they would be pulled from 
>> there when LogService requests
>> were made.
>>
>> This was to be able to support multiple languages, and in general 
>> just to support other registries besides
>> the existing OpenBMC one that is hardcoded in a header file. (We're 
>> going to have an IBM registry we
>> use together with our D-Bus logs based LogService.)
>
> There's 3 registries, fwiw: 
> https://github.com/openbmc/bmcweb/tree/master/redfish-core/include/registries
>
>>
>> An open issue we still had was if these registries had to be 
>> validated, or if that was left to whoever
>> made them.  A stake in the ground could be that we leave the OpenBMC 
>> registry as it is in a header
>> file, which negates validation, or put it in JSON too and validate 
>> just that one during the build.
>> Or if there are any other ideas here...
>
> Entity-manager uses valijson, in that way you could validate them 
> against a schema: https://github.com/tristanpenman/valijson. It plays 
> nicely with nlohmann-json. Although if these are compiled in json 
> files, I'm not sure it's a large issue. We could just create a 
> compile-time script to validate.
>
>>
>> As far as the directory used, I think that /usr/share/bmcweb/ would 
>> be appropriate, or maybe
>> /usr/share/bmcweb/registries/ if either of those are OK with you.
>
> I think the directory is a good idea so it can load any json file from 
> that directory. Maybe /usr/share/bmcweb/registries/<language> even to 
> make it easier to switch between languages?
>
>>
>> Also, it may be overkill to need to  read in the same registry for 
>> every language, as there could
>> be dozens and realistically they will never all be used on a single 
>> system, but if the desire is only
>> to load them at startup before the current language is known I don't 
>> really see a way around it.
>
> I think this would require a default language and a bmcweb reload if 
> the language changed? Its probably ok to change languages after 
> startup, as long as the default language is loaded immediately to 
> lower the chances of run-time issues. As changing languages is 
> probably a very infrequent operation.
>
>>
>> Thanks!
>> Matt