Re: entity manager configurations and dbus interfaces

From: James Feist <james.feist@linux.intel.com>
To: Ed Tanous <ed@tanous.net>, Brad Bishop <bradleyb@fuzziesquirrel.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: entity manager configurations and dbus interfaces
Date: Thu, 24 Sep 2020 09:38:42 -0700	[thread overview]
Message-ID: <cc51f754-93d2-c2be-ba29-17ecb50ecac0@linux.intel.com> (raw)
In-Reply-To: <CACWQX82BLnW9joot+VmLZGydCBm2riQ88Ncq9twqyf0UJdrtNw@mail.gmail.com>

On 9/24/2020 8:50 AM, Ed Tanous wrote:
> On Thu, Sep 24, 2020 at 7:30 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>>
>> Hi Ed
>>
>> Will quote a comment from this EM review:
>>
>> https://gerrit.openbmc-project.xyz/36702
>>
>>> entity-manager was designed with the tenant that it config files have
>>> no knowledge of dbus.
>>
>> FWIW I had no idea this was the case.
>>
>>> We've broken that a little with the inventory interfaces on the entity
>>> as a short term patch to gain some compatibility, but its easy enough
>>> to roll back in the future.
>>
>> Interesting - so there is a vision here, but I have no idea what it is.
>> Can you elaborate on how you envision inventory working if EM is not
>> implementing the inventory dbus interfaces?
> 
> In the simplest terms, one goal of entity-manager is for an engineer
> unfamiliar with OpenBMC to be able to add support for a new component,
> be it a baseboard, drive, or add in card, in less than a day.  Dbus
> APIs take more than a day to learn, so we need to find a way to
> provide a syntax that is self describing (and ideally well documented,
> but that's another issue that I'm hoping to tackle soon) as well as
> relatively isolated from the complexities of the OpenBMC core.
> 
> Another advantage of this is portability, if any wide sweeping
> architecture changes happen (ex, we rewrite the core in rust or we
> build a DBusless OpenBMC) we have a minimum definition of the things
> that are unique about the pieces of hardware we support, and don't
> have to re-engineer every piece of hardware that's in the list.
> 

While I agree with this, to fit in the current architecture, I'm not 
sure its entirely possible. We already expose some d-bus interfaces from 
the configuration files: 
https://github.com/openbmc/entity-manager/blob/0a2ab3c911d35c4c8421c47a7ce83d9341237785/configurations/WFT%20Baseboard.json#L1601. 
This particular change does add a new prescience to be able to add them 
anywhere, which I don't think should be taken lightly. However I'm not 
sure if there's any better way to support lower level assets interfaces 
such as a Fan FRU, unless you think it'd be better to add that to the 
FanSensor? I'm not sure I like that idea any better.

> 
>>
>> thx - brad