archive mirror
 help / color / mirror / Atom feed
From: Brad Bishop <>
To: George Liu <>
Cc: Devender Rao <>,
	OpenBMC Maillist <>
Subject: Re: Question regarding phosphor-dbus-monitor repo
Date: Thu, 16 Sep 2021 08:26:52 -0400	[thread overview]
Message-ID: <20210916122652.qi553jxvvvhtnkdn@cheese> (raw)
In-Reply-To: <>

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

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,

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.


  reply	other threads:[~2021-09-16 12:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16  7:24 Question regarding phosphor-dbus-monitor repo George Liu
2021-09-16 12:26 ` Brad Bishop [this message]
2021-09-16 18:42   ` John Broadbent
2021-09-16 23:55   ` Andrew Jeffery

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210916122652.qi553jxvvvhtnkdn@cheese \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).