A long time ago I made a proposal to unify the YAML template parsing code.

See:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/37461/4/designs/ipmi-static-configs-refactor.md#24

Many repos have copy/pasted and slightly modified the parsing, I think they could be unified again. But I have been busy lately 

On Thu, Sep 16, 2021 at 5:27 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
Hi George

On Thu, Sep 16, 2021 at 03:24:09PM +0800, George Liu wrote:

>The current default configuration has the realization of `OCC`
Hm.  That probably shouldn't be in the default configuration.

>1. Today the architecture of openBmc is gradually discarding YAML
>files right (because I think it requires templates and py paarsing to
>support).

And because this technique has proven to make it difficult to support
multiple configurations or combinations of hardware in a single image.
For example, supporting two different revisions of the same board with
minor differences.

>2. I think we can migrate the functions of this repo to the
>corresponding repo

Sounds fine on the surface.  Personally, I would like to see any and all
configuration moved to entity manager, so it is all in the same place. 
Some system integrators are not software developers and do not want to
hunt for configuration spread across different repositories or bitbake
metadata layers.  But the community is split on this - there is a
concern with making every application have a dependency on
entity-manager, which is an understandable concern.

>I suspect that the original design idea was to aggregate all D-Bus
>monitoring into this repo

Sort of.  The intent of the code was to provide a way to implement a
wide variety of highly specific policy.  For example: shut down the
system when more than 4 processor cores are hotter than 100 degrees C if
the chassis is water cooled.  Policy that has broad applicability would
be implemented closer to the application - so it wasn't really meant to
aggregate _all_ policy in the system.  Just the really esoteric stuff. 
In hindsight, I think it is too abstract and enables too much
logic implemented with data.

>4. At present, most repos use D-Bus to monitor certain attributes,
>objectPaths, etc, but they have not done YAML file adaptation in this
>repo, but implemented in their respective repos (eg: PLDM,
>phosphor-led-manager).

For the led applications, again, I would like to see those get their
configuration from entity-manager.  I don't think PLDM should have any
configuration files at all.

>So, my thoughts is: If we transplant `OCC` & `snmp` and other
>functions to their respective repos one day in the future, can this
>repo be discarded?

Sure - my long term goal for IBM systems anyway is to not be using this
application.  If noone else in the OpenBMC community is using it - sure
we could discard it entirely.

-brad