Re: Intel-ipmi-oem repo

Re: Intel-ipmi-oem repo

[Willy Tu]

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

> Team,
> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I
see several functionality in this repo like sensors and storage commands
are generic enough to be used by other platform who is using entity
manager. So I feel that we should have these functionalities to be moved to
a separate common repo which can be used by everyone and this repo can only
contain Intel OEM specific IPMI command support.
>
> My 2 cents 😊

Hi All,

I guess I'll start working on this if no one has any objection to it.

As mentioned in the beginning of the thread. The plan is to break down the
intel-ipmi-oem repo into two parts.
- True OEM at Intel
- Dynamic Sensor stacks (new repo)

The new repo could be named dbus-sdr or dbus-ipmi-sdr?
and will include the sensor and storage commands as mentioned.

Please let me know if there are any suggestions or concerns.

Best,

Willy Tu

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

Re: Intel-ipmi-oem repo

[Brad Bishop]

On Tue, Jan 12, 2021 at 06:54:14PM -0800, Willy Tu wrote:
>> Team,
>> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I
>see several functionality in this repo like sensors and storage commands
>are generic enough to be used by other platform who is using entity
>manager. So I feel that we should have these functionalities to be moved to
>a separate common repo which can be used by everyone and this repo can only
>contain Intel OEM specific IPMI command support.
>>
>> My 2 cents 😊
>
>Hi All,
>
>I guess I'll start working on this if no one has any objection to it.

Awesome!

>As mentioned in the beginning of the thread. The plan is to break down the
>intel-ipmi-oem repo into two parts.
>- True OEM at Intel
>- Dynamic Sensor stacks (new repo)

Why is dynamic sensor stacks a new repo?  I would like to see this done 
in the existing ipmid repo.  If the default implementations there today 
are undesired, I'd be fine with seeing those moved to the 
openpower-ipmi-oem repository.

FWIW I would like to make use of dynamic SDR on my new systems (I work 
for IBM) but I still have to maintain support for Witherspoon, which 
relies on the old fixed & hardcoded sensor identifiers.

-brad

Re: Intel-ipmi-oem repo

[Ed Tanous]

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

On Thu, Jan 14, 2021 at 6:40 AM Brad Bishop <bradleyb@fuzziesquirrel.com>
wrote:

> On Tue, Jan 12, 2021 at 06:54:14PM -0800, Willy Tu wrote:
> >> Team,
> >> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I
> >see several functionality in this repo like sensors and storage commands
> >are generic enough to be used by other platform who is using entity
> >manager. So I feel that we should have these functionalities to be moved
> to
> >a separate common repo which can be used by everyone and this repo can
> only
> >contain Intel OEM specific IPMI command support.
> >>
> >> My 2 cents 😊
> >
> >Hi All,
> >
> >I guess I'll start working on this if no one has any objection to it.
>
> Awesome!
>
> >As mentioned in the beginning of the thread. The plan is to break down the
> >intel-ipmi-oem repo into two parts.
> >- True OEM at Intel
> >- Dynamic Sensor stacks (new repo)
>
> Why is dynamic sensor stacks a new repo?  I would like to see this done
> in the existing ipmid repo.  If the default implementations there today
> are undesired, I'd be fine with seeing those moved to the
> openpower-ipmi-oem repository.
>

I only suggested a new repo originally because today it's a separate repo,
and the long ago patch to add it directly to ipmid got the feedback that
was too different than the existing to go there.  If we're now ok with it
going in IPMID, I'd prefer that as well.

Would people prefer it to be a package config on IPMID to select between
the two implementations?


>
> FWIW I would like to make use of dynamic SDR on my new systems (I work
> for IBM) but I still have to maintain support for Witherspoon, which
> relies on the old fixed & hardcoded sensor identifiers.
>
> -brad
>

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

Re: Intel-ipmi-oem repo

[Vernon Mauery]

On 14-Jan-2021 08:38 AM, Ed Tanous wrote:
>On Thu, Jan 14, 2021 at 6:40 AM Brad Bishop <bradleyb@fuzziesquirrel.com>
>wrote:
>
>> On Tue, Jan 12, 2021 at 06:54:14PM -0800, Willy Tu wrote:
>> >> Team,
>> >> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I
>> >see several functionality in this repo like sensors and storage commands
>> >are generic enough to be used by other platform who is using entity
>> >manager. So I feel that we should have these functionalities to be moved
>> to
>> >a separate common repo which can be used by everyone and this repo can
>> only
>> >contain Intel OEM specific IPMI command support.
>> >>
>> >> My 2 cents 😊
>> >
>> >Hi All,
>> >
>> >I guess I'll start working on this if no one has any objection to it.
>>
>> Awesome!
>>
>> >As mentioned in the beginning of the thread. The plan is to break down the
>> >intel-ipmi-oem repo into two parts.
>> >- True OEM at Intel
>> >- Dynamic Sensor stacks (new repo)
>>
>> Why is dynamic sensor stacks a new repo?  I would like to see this done
>> in the existing ipmid repo.  If the default implementations there today
>> are undesired, I'd be fine with seeing those moved to the
>> openpower-ipmi-oem repository.
>>
>
>I only suggested a new repo originally because today it's a separate repo,
>and the long ago patch to add it directly to ipmid got the feedback that
>was too different than the existing to go there.  If we're now ok with it
>going in IPMID, I'd prefer that as well.
>
>Would people prefer it to be a package config on IPMID to select between
>the two implementations?

I don't have a problem with a package config to select sensor 
implementations.

>
>>
>> FWIW I would like to make use of dynamic SDR on my new systems (I work
>> for IBM) but I still have to maintain support for Witherspoon, which
>> relies on the old fixed & hardcoded sensor identifiers.

I would say that if IBM is the only company using the sensor 
implementation that is currently in ipmid, it would be best to move it 
to the IBM OEM layer. But it is difficult in a project this size who is 
using what. So leaving it in ipmid for now is fine.

--Vernon

Re: Intel-ipmi-oem repo

[Brad Bishop]

On Thu, Jan 14, 2021 at 09:38:05AM -0800, Vernon Mauery wrote:
>On 14-Jan-2021 08:38 AM, Ed Tanous wrote:

>>Would people prefer it to be a package config on IPMID to select between
>>the two implementations?
>
>I don't have a problem with a package config to select sensor 
>implementations.

This seems fine to me too.  I looked and there are non-POWER users of 
the fixed sensor id implementation too so openpower-ipmi-oem probably 
doesn't make good sense.

>I would say that if IBM is the only company using the sensor 
>implementation that is currently in ipmid, it would be best to move it 
>to the IBM OEM layer. But it is difficult in a project this size who 
>is using what.

'grep yaml-config' of the openbmc tree gives a pretty decent indicator 
of who is using the fixed sensor ID implementation.

-brad

Re: Intel-ipmi-oem repo

[Ed Tanous]

On Thu, Jan 14, 2021 at 11:40 AM Brad Bishop
<bradleyb@fuzziesquirrel.com> wrote:
>
> On Thu, Jan 14, 2021 at 09:38:05AM -0800, Vernon Mauery wrote:
> >On 14-Jan-2021 08:38 AM, Ed Tanous wrote:
>
> >>Would people prefer it to be a package config on IPMID to select between
> >>the two implementations?
> >
> >I don't have a problem with a package config to select sensor
> >implementations.
>
> This seems fine to me too.  I looked and there are non-POWER users of
> the fixed sensor id implementation too so openpower-ipmi-oem probably
> doesn't make good sense.
>
> >I would say that if IBM is the only company using the sensor
> >implementation that is currently in ipmid, it would be best to move it
> >to the IBM OEM layer. But it is difficult in a project this size who
> >is using what.
>
> 'grep yaml-config' of the openbmc tree gives a pretty decent indicator
> of who is using the fixed sensor ID implementation.
>
> -brad

It's been on my list for a while to write a script to go build at
least rudimentary ported entity-manager configs for the existing
hardware in the tree.  I'd asked James to write this a few times in
the past, but as we know, we all get busy.  This is just to say, it's
on my radar to try to try to make this better.

-Ed

Re: Intel-ipmi-oem repo

[Willy Tu]

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

Ok, sounds good.

I'll look into moving to the IPMID repo with a package config instead.

Maybe we'll get more suggestions in this thread, but  I'll start work in
that direction.

Willy Tu

On Thu, Jan 14, 2021 at 12:06 PM Ed Tanous <edtanous@google.com> wrote:

> On Thu, Jan 14, 2021 at 11:40 AM Brad Bishop
> <bradleyb@fuzziesquirrel.com> wrote:
> >
> > On Thu, Jan 14, 2021 at 09:38:05AM -0800, Vernon Mauery wrote:
> > >On 14-Jan-2021 08:38 AM, Ed Tanous wrote:
> >
> > >>Would people prefer it to be a package config on IPMID to select
> between
> > >>the two implementations?
> > >
> > >I don't have a problem with a package config to select sensor
> > >implementations.
> >
> > This seems fine to me too.  I looked and there are non-POWER users of
> > the fixed sensor id implementation too so openpower-ipmi-oem probably
> > doesn't make good sense.
> >
> > >I would say that if IBM is the only company using the sensor
> > >implementation that is currently in ipmid, it would be best to move it
> > >to the IBM OEM layer. But it is difficult in a project this size who
> > >is using what.
> >
> > 'grep yaml-config' of the openbmc tree gives a pretty decent indicator
> > of who is using the fixed sensor ID implementation.
> >
> > -brad
>
> It's been on my list for a while to write a script to go build at
> least rudimentary ported entity-manager configs for the existing
> hardware in the tree.  I'd asked James to write this a few times in
> the past, but as we know, we all get busy.  This is just to say, it's
> on my radar to try to try to make this better.
>
> -Ed
>

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

Re: Intel-ipmi-oem repo

[Lei Yu]

On Fri, Jan 15, 2021 at 3:23 AM Vernon Mauery
<vernon.mauery@linux.intel.com> wrote:
> I would say that if IBM is the only company using the sensor
> implementation that is currently in ipmid, it would be best to move it
> to the IBM OEM layer. But it is difficult in a project this size who is
> using what. So leaving it in ipmid for now is fine.
>

This is not the case. Bytedance uses ipmid with fixed yaml as well.
In our case, we have all the sensors on DBus created by
entity-manager/dbus-sensors, and only part of them are necessary for
ipmi.
So we specifically define the necessary sensors (and
inventory-sensors) in yaml and use the current ipmid to implement
them.

AFAIK Yadro and Ampere uses ipmid with fixed yaml too.

-- 
BRs,
Lei YU

Re: Re: Intel-ipmi-oem repo

[chunhui.jia]

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

You use both fixed sensor and dynamic sensors?

2021-01-15 

chunhui.jia 



发件人：Lei Yu <yulei.sh@bytedance.com>
发送时间：2021-01-15 10:23
主题：Re: Intel-ipmi-oem repo
收件人："Vernon Mauery"<vernon.mauery@linux.intel.com>
抄送："Willy Tu"<wltu@google.com>,"OpenBMC Maillist"<openbmc@lists.ozlabs.org>,"chunhui.jia"<chunhui.jia@linux.intel.com>,"Ed Tanous"<edtanous@google.com>,"Brad Bishop"<bradleyb@fuzziesquirrel.com>,"apparao.puli"<apparao.puli@linux.intel.com>,"Vijay Khemka"<vijaykhemka@fb.com>

On Fri, Jan 15, 2021 at 3:23 AM Vernon Mauery 
<vernon.mauery@linux.intel.com> wrote: 
> I would say that if IBM is the only company using the sensor 
> implementation that is currently in ipmid, it would be best to move it 
> to the IBM OEM layer. But it is difficult in a project this size who is 
> using what. So leaving it in ipmid for now is fine. 
> 

This is not the case. Bytedance uses ipmid with fixed yaml as well. 
In our case, we have all the sensors on DBus created by 
entity-manager/dbus-sensors, and only part of them are necessary for 
ipmi. 
So we specifically define the necessary sensors (and 
inventory-sensors) in yaml and use the current ipmid to implement 
them. 

AFAIK Yadro and Ampere uses ipmid with fixed yaml too. 

--  
BRs, 
Lei YU 

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

Re: Intel-ipmi-oem repo

[Lei Yu]

On Fri, Jan 15, 2021 at 12:20 PM chunhui.jia
<chunhui.jia@linux.intel.com> wrote:
>
> You use both fixed sensor and dynamic sensors?

Not exactly.
We use "dynamic sensors" created by entity-manager/dbus-sensors on DBus;
We use "fixed sensors" with phosphor-host-ipmid defined in yaml.

>
> 发件人：Lei Yu <yulei.sh@bytedance.com>
> 发送时间：2021-01-15 10:23
> 主题：Re: Intel-ipmi-oem repo
> 收件人："Vernon Mauery"<vernon.mauery@linux.intel.com>
> 抄送："Willy Tu"<wltu@google.com>,"OpenBMC Maillist"<openbmc@lists.ozlabs.org>,"chunhui.jia"<chunhui.jia@linux.intel.com>,"Ed Tanous"<edtanous@google.com>,"Brad Bishop"<bradleyb@fuzziesquirrel.com>,"apparao.puli"<apparao.puli@linux.intel.com>,"Vijay Khemka"<vijaykhemka@fb.com>
>
> On Fri, Jan 15, 2021 at 3:23 AM Vernon Mauery
> <vernon.mauery@linux.intel.com> wrote:
> > I would say that if IBM is the only company using the sensor
> > implementation that is currently in ipmid, it would be best to move it
> > to the IBM OEM layer. But it is difficult in a project this size who is
> > using what. So leaving it in ipmid for now is fine.
> >
>
> This is not the case. Bytedance uses ipmid with fixed yaml as well.
> In our case, we have all the sensors on DBus created by
> entity-manager/dbus-sensors, and only part of them are necessary for
> ipmi.
> So we specifically define the necessary sensors (and
> inventory-sensors) in yaml and use the current ipmid to implement
> them.
>
> AFAIK Yadro and Ampere uses ipmid with fixed yaml too.
>
> --
> BRs,
> Lei YU



-- 
BRs,
Lei YU

Re: Intel-ipmi-oem repo

[Brad Bishop]

On Thu, Jan 14, 2021 at 08:38:41AM -0800, Ed Tanous wrote:

>I only suggested a new repo originally because today it's a separate repo,
>and the long ago patch to add it directly to ipmid got the feedback that
>was too different than the existing to go there.  

Hrm...this is not at all how I remember it.  I thought the feedback IBM 
tried to give back then was "please don't break the code that is already 
there."  I apologize if what came through was "your code is too 
different, no thanks" ...that was definitely never the intent.

-brad

Re: Intel-ipmi-oem repo

[Ed Tanous]

On Thu, Jan 14, 2021 at 10:53 AM Brad Bishop
<bradleyb@fuzziesquirrel.com> wrote:
>
> On Thu, Jan 14, 2021 at 08:38:41AM -0800, Ed Tanous wrote:
>
> >I only suggested a new repo originally because today it's a separate repo,
> >and the long ago patch to add it directly to ipmid got the feedback that
> >was too different than the existing to go there.
>
> Hrm...this is not at all how I remember it.  I thought the feedback IBM
> tried to give back then was "please don't break the code that is already
> there."  I apologize if what came through was "your code is too
> different, no thanks" ...that was definitely never the intent.
>
> -brad

I was only tangentially related to the previous discussion, so it's
quite likely I got some details wrong.  Sounds like we have a path
forward that doesn't break anyone, so on that front, I think we're
good to get the work done.

-Ed

Intel-ipmi-oem repo

[Vijay Khemka]

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

Team,
Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I see several functionality in this repo like sensors and storage commands are generic enough to be used by other platform who is using entity manager. So I feel that we should have these functionalities to be moved to a separate common repo which can be used by everyone and this repo can only contain Intel OEM specific IPMI command support.

My 2 cents 😊

Regards
-Vijay


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

Re: Intel-ipmi-oem repo

[Brad Bishop]

On Tue, Jan 22, 2019 at 06:16:20PM +0000, Vijay Khemka wrote:
> Team,
> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I see several functionality in this repo like sensors and storage commands are generic enough to be used by other platform who is using entity manager. So I feel that we should have these functionalities to be moved to a separate common repo which can be used by everyone and this repo can only contain Intel OEM specific IPMI command support.
> 
> My 2 cents 😊

In general I support the goal here.

More repos, sure.  Let me know what you want them called, who the
maintainers of each should be, and confirm that they can be licensed
as Apache-2.0.

Sorry Vijay - I'm going to hijack your thread.  This is something
I've been thinking about lately and your note put it at a tipping
point for me.

We have evolved into a bit of a wild-west culture as far as putting code
(repos) up in the openbmc namespace.  There are simply no rules at all.
Anyone can simply ask Brad for a repo and it gets created, no questions
asked, no accountability.

So I guess a quick poll - does anyone find this concerning (or not)?

fwiw, I think I'm ok with this model at this point in the project,
assuming that the rules (or lack thereof) apply to everyone equally.

thx - brad

Re: Intel-ipmi-oem repo

[Patrick Venture]

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

On Tue, Jan 22, 2019 at 12:53 PM Brad Bishop <bradleyb@fuzziesquirrel.com>
wrote:

> On Tue, Jan 22, 2019 at 06:16:20PM +0000, Vijay Khemka wrote:
> > Team,
> > Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I
> see several functionality in this repo like sensors and storage commands
> are generic enough to be used by other platform who is using entity
> manager. So I feel that we should have these functionalities to be moved to
> a separate common repo which can be used by everyone and this repo can only
> contain Intel OEM specific IPMI command support.
> >
> > My 2 cents 😊
>
> In general I support the goal here.
>
> More repos, sure.  Let me know what you want them called, who the
> maintainers of each should be, and confirm that they can be licensed
> as Apache-2.0.
>
> Sorry Vijay - I'm going to hijack your thread.  This is something
> I've been thinking about lately and your note put it at a tipping
> point for me.
>
> We have evolved into a bit of a wild-west culture as far as putting code
> (repos) up in the openbmc namespace.  There are simply no rules at all.
> Anyone can simply ask Brad for a repo and it gets created, no questions
> asked, no accountability.
>
> So I guess a quick poll - does anyone find this concerning (or not)?
>

I'm holding the hypothesis that things expand for a bit, and then fall back
onto themselves. -- which maybe isn't the best approach.  I could be wrong,
it could be the universe expanding and accelerating, which has the
unfortunate consequence of moving galaxies further apart -- code less
compatible or allowing more duplication.


>
> fwiw, I think I'm ok with this model at this point in the project,
> assuming that the rules (or lack thereof) apply to everyone equally.
>
> thx - brad
>

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

Re: Intel-ipmi-oem repo

[Vijay Khemka]

On 1/22/19, 12:53 PM, "Brad Bishop" <bradleyb@fuzziesquirrel.com> wrote:

    On Tue, Jan 22, 2019 at 06:16:20PM +0000, Vijay Khemka wrote:
    > Team,
    > Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I see several functionality in this repo like sensors and storage commands are generic enough to be used by other platform who is using entity manager. So I feel that we should have these functionalities to be moved to a separate common repo which can be used by everyone and this repo can only contain Intel OEM specific IPMI command support.
    > 
    > My 2 cents 😊
    
    In general I support the goal here.
    
    More repos, sure.  Let me know what you want them called, who the
    maintainers of each should be, and confirm that they can be licensed
    as Apache-2.0.
Yes, I would prefer more of generic code approach which can benefit many users.
Ultimate goal is more manageable code and useful to everyone.
    
    Sorry Vijay - I'm going to hijack your thread.  This is something
    I've been thinking about lately and your note put it at a tipping
    point for me.
No issue Brad. 
    
    We have evolved into a bit of a wild-west culture as far as putting code
    (repos) up in the openbmc namespace.  There are simply no rules at all.
    Anyone can simply ask Brad for a repo and it gets created, no questions
    asked, no accountability.
    
    So I guess a quick poll - does anyone find this concerning (or not)?
    
    fwiw, I think I'm ok with this model at this point in the project,
    assuming that the rules (or lack thereof) apply to everyone equally.
    
    thx - brad
    

Re: Intel-ipmi-oem repo

[Ed Tanous]

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

On 1/22/19 10:16 AM, Vijay Khemka wrote:
>
> Team,
>
> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific.
> I see several functionality in this repo like sensors and storage
> commands are generic enough to be used by other platform who is using
> entity manager. So I feel that we should have these functionalities to
> be moved to a separate common repo which can be used by everyone and
> this repo can only contain Intel OEM specific IPMI command support.
>
When this work was first started, the hope was that the SDR, SEL and the
sensor numbering changes could be rolled out to the whole project as the
"standard", and that this was just a staging area.  Unfortunately, when
we tried to push them, we got some late breaking feedback from the
maintainer that some flows (like writing sensor values from the host)
would break IBM systems.  Given that our systems didn't require or
implement those flows, we didn't have a very clear path forward for how
to get them upstreamed, and eventually ran out of time waiting for
responses.

The last thread I recall on the issue was here, where the maintainer
documented some of the issues that were present on IBM systems with
those command sets.  There were several other gerrit reviews that I can
find if needed, but they basically boiled down to what's in the thread
below.

https://lists.ozlabs.org/pipermail/openbmc/2018-November/014139.html

Given that it sounds like the community is interested in these changes
being rolled out to more than just intel systems, I suspect we need to
continue that discussion.

For reference, the changes being mentioned enable:

1. Dynamic IPMI sensor creation based on dbus mapper reflection, rather
than hardcoded paths and sensor numbers.
2. Automatic generation of type 1 SDRs (including M and B scaling) from
dbus interfaces.
3. Automatic generation of FRU sdr records based on dbus interfaces.

There are probably other things that I'm forgetting, but these are the
highlights.

Tom,

Do you think that you could propose a path that would allow these
changes into the mainstream, while still keeping IBM systems
functional?  Based on comments that I've heard both in person, and on
other gerrit reviews, I believe these changes have some level of support
from the other two IPMI maintainers (correct me if I'm wrong guys).


If the final answer is that we really need yet another repo, so be it,
I'm happy to help maintain it, but given the interest, we should at
least investigate the possibility of making this the "standard" going
forward.

>  
>
> My 2 cents 😊
>
Much appreciated.

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

Re: Intel-ipmi-oem repo

[Vijay Khemka]

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

If we can manage this in standard repo with some compile time config parameter to use chosen approach. It will help in maintaining multiple repo.

From: openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> on behalf of Ed Tanous <ed.tanous@intel.com>
Date: Tuesday, January 22, 2019 at 2:04 PM
To: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Intel-ipmi-oem repo

On 1/22/19 10:16 AM, Vijay Khemka wrote:
Team,
Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I see several functionality in this repo like sensors and storage commands are generic enough to be used by other platform who is using entity manager. So I feel that we should have these functionalities to be moved to a separate common repo which can be used by everyone and this repo can only contain Intel OEM specific IPMI command support.

When this work was first started, the hope was that the SDR, SEL and the sensor numbering changes could be rolled out to the whole project as the "standard", and that this was just a staging area.  Unfortunately, when we tried to push them, we got some late breaking feedback from the maintainer that some flows (like writing sensor values from the host) would break IBM systems.  Given that our systems didn't require or implement those flows, we didn't have a very clear path forward for how to get them upstreamed, and eventually ran out of time waiting for responses.

The last thread I recall on the issue was here, where the maintainer documented some of the issues that were present on IBM systems with those command sets.  There were several other gerrit reviews that I can find if needed, but they basically boiled down to what's in the thread below.

https://lists.ozlabs.org/pipermail/openbmc/2018-November/014139.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2018-2DNovember_014139.html&d=DwMDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=lOhC8y7KcU3Q2RQ4jonrvsNVb2z07MgDTeXIa_NEIF0&s=qW9KX6eEa1B2cCUHKqZRGZtLSb7KCrK9SON3S5AWYG8&e=>

Given that it sounds like the community is interested in these changes being rolled out to more than just intel systems, I suspect we need to continue that discussion.

For reference, the changes being mentioned enable:

1. Dynamic IPMI sensor creation based on dbus mapper reflection, rather than hardcoded paths and sensor numbers.
2. Automatic generation of type 1 SDRs (including M and B scaling) from dbus interfaces.
3. Automatic generation of FRU sdr records based on dbus interfaces.

There are probably other things that I'm forgetting, but these are the highlights.

Tom,

Do you think that you could propose a path that would allow these changes into the mainstream, while still keeping IBM systems functional?  Based on comments that I've heard both in person, and on other gerrit reviews, I believe these changes have some level of support from the other two IPMI maintainers (correct me if I'm wrong guys).



If the final answer is that we really need yet another repo, so be it, I'm happy to help maintain it, but given the interest, we should at least investigate the possibility of making this the "standard" going forward.

My 2 cents 😊
Much appreciated.


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

Re: Intel-ipmi-oem repo

[Ed Tanous]

On 1/22/19 2:22 PM, Vijay Khemka wrote:
> If we can manage this in standard repo with some compile time config
> parameter to use chosen approach. It will help in maintaining multiple repo.
> 
>  

I believe this was proposed at one point on one of the calls, but I
don't remember what the conclusion was.  Based on my understanding it
was possible technically, but then we went down the rabbit hole of
trying to make a single solution that met everyone's needs.  We could
certainly start moving in the direction of an #ifdef to support both
ways, with the eventual hope that we could converge on a single solution.

Re: Intel-ipmi-oem repo

[Vijay Khemka]

On 1/22/19, 3:23 PM, "Ed Tanous" <ed.tanous@intel.com> wrote:

    On 1/22/19 2:22 PM, Vijay Khemka wrote:
    > If we can manage this in standard repo with some compile time config
    > parameter to use chosen approach. It will help in maintaining multiple repo.
    > 
    >  
    
    I believe this was proposed at one point on one of the calls, but I
    don't remember what the conclusion was.  Based on my understanding it
    was possible technically, but then we went down the rabbit hole of
    trying to make a single solution that met everyone's needs.  We could
    certainly start moving in the direction of an #ifdef to support both
    ways, with the eventual hope that we could converge on a single solution.
    
Currently we have only 2 approach which we use for fru either phosphor-fru or entity manager. To use IPMI fru and sensor command one has to follow either approach and both approach have its own ways of handling IPMI command request so either we define some config option or we mention which file to include for IPMI command considering each file will have its own approach or we link these commands to entity manager module which will expose Fru interface to dbus then it will also register the similar IPMI command implementation. As it is tightly coupled we need to maintain this way. Otherwise it will hard to maintain and explain user which one to use.

Regards
-Vijay

Re: Intel-ipmi-oem repo

[Bills, Jason M]

On 1/22/2019 2:22 PM, Vijay Khemka wrote:
> If we can manage this in standard repo with some compile time config 
> parameter to use chosen approach. It will help in maintaining multiple repo.

I have uploaded a new patch set to 
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-host-ipmid/+/12951 
that keeps the current behavior as a default and adds a compile option 
to switch to the journal-based SEL.  Perhaps it is a better option than 
the intel-ipmi-oem repo while we work out the sensor numbering?

Please check it out and provide thoughts and feedback.

Thanks,
-Jason

Re: Intel-ipmi-oem repo

[Tom Joseph]

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



On Wednesday 23 January 2019 03:35 AM, Ed Tanous wrote:
> On 1/22/19 10:16 AM, Vijay Khemka wrote:
>>
>> Team,
>>
>> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. 
>> I see several functionality in this repo like sensors and storage 
>> commands are generic enough to be used by other platform who is using 
>> entity manager. So I feel that we should have these functionalities 
>> to be moved to a separate common repo which can be used by everyone 
>> and this repo can only contain Intel OEM specific IPMI command support.
>>
> When this work was first started, the hope was that the SDR, SEL and 
> the sensor numbering changes could be rolled out to the whole project 
> as the "standard", and that this was just a staging area.  
> Unfortunately, when we tried to push them, we got some late breaking 
> feedback from the maintainer that some flows (like writing sensor 
> values from the host) would break IBM systems.  Given that our systems 
> didn't require or implement those flows, we didn't have a very clear 
> path forward for how to get them upstreamed, and eventually ran out of 
> time waiting for responses.
>
This is disappointing to hear, feedback was provided as early as May 
2018 and discussed in the community calls earlier that that. 
(https://gerrit.openbmc-project.xyz/#/c/openbmc/s2600wf-misc/+/8521/). 
The major point of concern was arbitrary sensor numbers and the solution 
was a flexible way to assign sensor numbers to sensor D-bus objects.
>
> The last thread I recall on the issue was here, where the maintainer 
> documented some of the issues that were present on IBM systems with 
> those command sets.  There were several other gerrit reviews that I 
> can find if needed, but they basically boiled down to what's in the 
> thread below.
>
> https://lists.ozlabs.org/pipermail/openbmc/2018-November/014139.html
>
> Given that it sounds like the community is interested in these changes 
> being rolled out to more than just intel systems, I suspect we need to 
> continue that discussion.
>
> For reference, the changes being mentioned enable:
>
> 1. Dynamic IPMI sensor creation based on dbus mapper reflection, 
> rather than hardcoded paths and sensor numbers.
> 2. Automatic generation of type 1 SDRs (including M and B scaling) 
> from dbus interfaces.
> 3. Automatic generation of FRU sdr records based on dbus interfaces.
>
> There are probably other things that I'm forgetting, but these are the 
> highlights.
>
> Tom,
>
> Do you think that you could propose a path that would allow these 
> changes into the mainstream, while still keeping IBM systems 
> functional?  Based on comments that I've heard both in person, and on 
> other gerrit reviews, I believe these changes have some level of 
> support from the other two IPMI maintainers (correct me if I'm wrong 
> guys).
>
In the case of SEL we did make progress and reached a consensus. The 
proposed solution was to support mapping sensor number to sensor D-Bus 
object paths in a flexible way(support both arbitrary mapping and 
hardcoded sensor number), so that IBM systems can coexist with the 
proposed SEL architecture. Jason was pursuing that and we haven't heard 
from him for quite some time, this was brought in the community call 
multiple times.

There was OpenPower OEM specific stuff in the standard implementation of 
the SEL and i am done with moving that to the OEM library.

If the final answer is that we really need yet another repo, so be it, 
I'm happy to help maintain it, but given the interest, we should at 
least investigate the possibility of making this the "standard" going 
forward.
>>
>> My 2 cents 😊
>>
> Much appreciated.


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

Re: Intel-ipmi-oem repo

[Ed Tanous]

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


On 1/22/19 10:13 PM, Tom Joseph wrote:
> On Wednesday 23 January 2019 03:35 AM, Ed Tanous wrote:
>> On 1/22/19 10:16 AM, Vijay Khemka wrote:
>>> In the case of SEL we did make progress and reached a consensus. The
>>> proposed solution was to support mapping sensor number to sensor
>>> D-Bus object paths in a flexible way(support both arbitrary mapping
>>> and hardcoded sensor number), so that IBM systems can coexist with
>>> the proposed SEL architecture. Jason was pursuing that and we
>>> haven't heard from him for quite some time, this was brought in the
>>> community call multiple times. =

I was unaware Jason was still pursuing that, my understanding was that
there wasn't a clear path forward for that change series to be
compatible with IBM systems.  Was there any details on what the proposed
solution was, and what the next steps are?  It sounds like Vijay is
hitting a bit of a wall with having that stuff checked into meta-intel; 
I'd much rather roll those changes out into net-ipmid than create a new
repo.

As Brad said earlier in the thread, the proliferation of repos is
getting a bit nutty, and I'd like to avoid it if at all possible.


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

Re: Intel-ipmi-oem repo

[Brad Bishop]

On Wed, Jan 23, 2019 at 08:34:51AM -0800, Ed Tanous wrote:
> 
> On 1/22/19 10:13 PM, Tom Joseph wrote:
> > On Wednesday 23 January 2019 03:35 AM, Ed Tanous wrote:
> >> On 1/22/19 10:16 AM, Vijay Khemka wrote:
> >>> In the case of SEL we did make progress and reached a consensus. The
> >>> proposed solution was to support mapping sensor number to sensor
> >>> D-Bus object paths in a flexible way(support both arbitrary mapping
> >>> and hardcoded sensor number), so that IBM systems can coexist with
> >>> the proposed SEL architecture. Jason was pursuing that and we
> >>> haven't heard from him for quite some time, this was brought in the
> >>> community call multiple times. =
> 
> I was unaware Jason was still pursuing that, my understanding was that
> there wasn't a clear path forward for that change series to be
> compatible with IBM systems.  

This should read:

a clear path forward for that change series to be compatible with every
user of the project since it started.  

It is a common misconception that IBM was the only user of/contributor
to this project prior to IBM donating it to The Linux Foundation last year.
In fact there were several contributors and users prior TLF.

> Was there any details on what the proposed
> solution was, and what the next steps are?

Just to level set - Do you expect Tom/IBM to provide the solution?  May I
ask why?  I felt the note from Tom spelled it out pretty clearly - an
abstraction is needed for sensor numbers.

> It sounds like Vijay is
> hitting a bit of a wall with having that stuff checked into meta-intel; 
> I'd much rather roll those changes out into net-ipmid than create a new
> repo.

Me too!

> 
> As Brad said earlier in the thread, the proliferation of repos is
> getting a bit nutty, and I'd like to avoid it if at all possible.
>