<div dir="ltr">A long time ago I made a proposal to unify the YAML template parsing code.<div><br></div><div>See:<br><div><a href="https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/37461/4/designs/ipmi-static-configs-refactor.md#24">https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/37461/4/designs/ipmi-static-configs-refactor.md#24</a><br></div></div><div><br></div><div>Many repos have copy/pasted and slightly modified the parsing, I think they could be unified again. But I have been busy lately </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 16, 2021 at 5:27 AM Brad Bishop <<a href="mailto:bradleyb@fuzziesquirrel.com">bradleyb@fuzziesquirrel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi George<br>
<br>
On Thu, Sep 16, 2021 at 03:24:09PM +0800, George Liu wrote:<br>
<br>
>The current default configuration has the realization of `OCC` <br>
Hm.  That probably shouldn't be in the default configuration.<br>
<br>
>1. Today the architecture of openBmc is gradually discarding YAML<br>
>files right (because I think it requires templates and py paarsing to<br>
>support).<br>
<br>
And because this technique has proven to make it difficult to support <br>
multiple configurations or combinations of hardware in a single image.<br>
For example, supporting two different revisions of the same board with <br>
minor differences.<br>
<br>
>2. I think we can migrate the functions of this repo to the<br>
>corresponding repo<br>
<br>
Sounds fine on the surface.  Personally, I would like to see any and all <br>
configuration moved to entity manager, so it is all in the same place.  <br>
Some system integrators are not software developers and do not want to <br>
hunt for configuration spread across different repositories or bitbake <br>
metadata layers.  But the community is split on this - there is a <br>
concern with making every application have a dependency on <br>
entity-manager, which is an understandable concern.<br>
<br>
>I suspect that the original design idea was to aggregate all D-Bus <br>
>monitoring into this repo<br>
<br>
Sort of.  The intent of the code was to provide a way to implement a <br>
wide variety of highly specific policy.  For example: shut down the <br>
system when more than 4 processor cores are hotter than 100 degrees C if <br>
the chassis is water cooled.  Policy that has broad applicability would <br>
be implemented closer to the application - so it wasn't really meant to <br>
aggregate _all_ policy in the system.  Just the really esoteric stuff.  <br>
In hindsight, I think it is too abstract and enables too much <br>
logic implemented with data.<br>
<br>
>4. At present, most repos use D-Bus to monitor certain attributes,<br>
>objectPaths, etc, but they have not done YAML file adaptation in this<br>
>repo, but implemented in their respective repos (eg: PLDM,<br>
>phosphor-led-manager).<br>
<br>
For the led applications, again, I would like to see those get their <br>
configuration from entity-manager.  I don't think PLDM should have any <br>
configuration files at all.<br>
<br>
>So, my thoughts is: If we transplant `OCC` & `snmp` and other<br>
>functions to their respective repos one day in the future, can this<br>
>repo be discarded?<br>
<br>
Sure - my long term goal for IBM systems anyway is to not be using this <br>
application.  If noone else in the OpenBMC community is using it - sure <br>
we could discard it entirely.<br>
<br>
-brad<br>
</blockquote></div>