Question regarding phosphor-dbus-monitor repo

[John Broadbent]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210916/b502e90e/attachment.htm>