Question regarding phosphor-dbus-monitor repo

Question regarding phosphor-dbus-monitor repo

[George Liu]

Hey everyone:

I am learning phosphor-dbus-monitor recently, It is used to monitor
the attribute value or objectPath of D-Bus, and then execute the
corresponding callback method, and the premise is that needs to
configure in the YAML file.

The current default configuration has the realization of `OCC` and
`snmp`, and I have also seen the realization of other functions in the
ibm openbmc repo(eg: Fan, PowerSupply, etc).

I have the following doubts:
1. Today the architecture of openBmc is gradually discarding YAML
files right (because I think it requires templates and py paarsing to
support).
2. I think we can migrate the functions of this repo to the
corresponding repo (eg: the configuration of OCC can be migrated to
openpower-occ-control, and the configuration of snmp can be migrated
to phosphor-snmp).
3. Adapting to these YAML is a complicated process, and I suspect that
the original design idea was to aggregate all D-Bus monitoring into
this repo, but it does not currently achieve this goal (maybe my
understanding is wrong).
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).

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?
Sorry, I am not sure if the maintainer has other plans, or there are
other advantages to using this repo? Maybe I missed something.

Looking forward to your reply :)

Thx - George Liu

Re: Question regarding phosphor-dbus-monitor repo

[Brad Bishop]

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

Re: Question regarding phosphor-dbus-monitor repo

[John Broadbent]

[-- Attachment #1: Type: text/plain, Size: 2966 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3718 bytes --]

Re: Question regarding phosphor-dbus-monitor repo

[Andrew Jeffery]

On Thu, 16 Sep 2021, at 21:56, Brad Bishop wrote:

> In hindsight, I think it is too abstract and enables too much 
> logic implemented with data.

+100