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