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

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.=C2=A0 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.=C2=A0 Personally, I would like to see any and a= ll
configuration moved to entity manager, so it is all in the same place.=C2= =A0
Some system integrators are not software developers and do not want to
hunt for configuration spread across different repositories or bitbake
metadata layers.=C2=A0 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.=C2=A0 The intent of the code was to provide a way to implement a <= br> wide variety of highly specific policy.=C2=A0 For example: shut down the system when more than 4 processor cores are hotter than 100 degrees C if the chassis is water cooled.=C2=A0 Policy that has broad applicability woul= d
be implemented closer to the application - so it wasn't really meant to=
aggregate _all_ policy in the system.=C2=A0 Just the really esoteric stuff.= =C2=A0
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.=C2=A0 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.=C2=A0 If noone else in the OpenBMC community is using it - sur= e
we could discard it entirely.

-brad