interest in a minimal image recipe

[Vijay Khemka]

On 9/23/20, 12:46 PM, "Ed Tanous" <ed at tanous.net> wrote:

    On Tue, Sep 22, 2020 at 1:40 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
    >
    >
    >
    > On 9/21/20, 10:57 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of bradleyb at fuzziesquirrel.com> wrote:
    >
    >     On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
    >     >On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
    >     >>
    >     >> In what way does EM require intel-ipmi-oem?  I am using EM without
    >     >> intel-ipmi-oem without (I thought anyway) issue.
    >     >
    >     >You're running Entity Manager, without intel-ipmi-oem, and you can run
    >     >a successful "ipmitool sensor list" or "ipmitool fru print" command,
    >     >and have it return the entity manager/dbus-sensors/FruDevice results?
    >
    >     Ah, now I understand.  No, I can't do that.  But I don't need to because
    >     the default IPMI handler implementations in phosphor-host-ipmid work for
    >     me (the YAML based ones), and those don't need entity-manager.  I'm
    >     using entity-manager for other reasons.
    >
    >     As an aside - I think a majority are using the intel-ipmi-oem handlers
    >     now so I'd support moving those into phosphor-host-ipmid and using them
    >     as the defaults.  But that must not be easy, otherwise Intel would have
    >     just done that rather than forking the handlers in intel-ipmi-oem in the
    >     first place.
    > I support moving many standard commands from intel-ipmi-oem to
    > phosphor-host-ipmid.  Entity manager is required only for fru and
    > sensor SDR ipmi command but there are many other commands
    > which are useful and can be moved.
    >
    >     But in any case, intel-ipmi-oem requires entity-manager, not the other
    >     way around right?  The "feature" being selected here is the Intel IPMI
    >     handler forks, and that would simply depend on entity-manager.  A
    >     strawman:
    >
    >     obmc-phosphor-image.bbclass:
    >     FEATURE_PACKAGES_intel-ipmi-handler-forks = "packagegroup-intel-ipmi-handler-forks"
    >
    >     packagegroup-obmc-apps.bb:
    >     RDEPENDS_packagegroup-obmc-apps-intel-ipmi-handler-forks = "intel-ipmi-oem"
    >
    >     intel-ipmi-oem.bb:
    >     RDEPENDS_${PN} = "entity-manager"
    >
    >     One prerequisite to this is that the intel-ipmi-oem recipe would need to
    >     move to meta-phosphor.  Perhaps its time for the repo to be renamed into
    >     something else.
    > We may have to split and look for what we need from intel-ipmi-oem. There
    > are lots of intel oem specific command in this which are not useful for
    > many other platforms and are overridden by their own xx-ipmi-oem.
    >
    > We should simply port standard ipmi command from intel-ipmi-oem to
    > Phosphor-host-ipmid.

    +1

    >
    >     >In my understanding, this shouldn't work, and we've had many reports
    >     >of "I enabled entity manager, and my sensors don't show up in IPMI".
    >     I don't think the answer to "how do I enable IPMI sensors" was ever
    >     "enable entity manager" was it?  To enable IPMI, you have always needed
    >     to enable either the original YAML based handlers or the intel-ipmi-oem
    >     forks.
    >
    > We should fix this in host-ipmid, as all sensors are added to standard dbus
    > Interface and if it is not discoverable by mapper or object manager then we
    > should fix it so that an SDR can be built independent of sensor implementation.
    >

    I agree with all the above.  Do you think you could get the patches
    pushed to start this discussion in gerrit?

Yes sure. once I finish my current tasks, I will schedule this.