New repository Request

New repository Request

[Patrick Venture]

Brad;

Please create: google-ipmi-sys -- this is to hold OEM IPMI commands we
want to share with the community and vendors, but dont' expect to be
picked up by OpenBMC at large, similar to intel-ipmi-oem.

Thanks,
Patrick

Re: New repository Request

[Brad Bishop]

> On Sep 14, 2018, at 7:57 PM, Patrick Venture <venture@google.com> wrote:
> 
> Brad;
> 
> Please create: google-ipmi-sys -- this is to hold OEM IPMI commands we
> want to share with the community and vendors, but dont' expect to be
> picked up by OpenBMC at large, similar to intel-ipmi-oem.

All the existing OEM IPMI repositories end with -ipmi-oem.  Does that not
make sense here?

Re: New repository Request

[Patrick Venture]

On Mon, Sep 17, 2018 at 7:03 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
>
>
> > On Sep 14, 2018, at 7:57 PM, Patrick Venture <venture@google.com> wrote:
> >
> > Brad;
> >
> > Please create: google-ipmi-sys -- this is to hold OEM IPMI commands we
> > want to share with the community and vendors, but dont' expect to be
> > picked up by OpenBMC at large, similar to intel-ipmi-oem.
>
> All the existing OEM IPMI repositories end with -ipmi-oem.  Does that not
> make sense here?

So phosphor-ipmi-blobs and phosphor-ipmi-flash are both ipmi-oem
libraries.  As well as phosphor-ipmi-ethstats.  My thinking was having
-ipmi- in the name was conveying sufficient information related to
this.

Re: New repository Request

[Brad Bishop]

> On Sep 17, 2018, at 1:20 PM, Patrick Venture <venture@google.com> wrote:
> 
> On Mon, Sep 17, 2018 at 7:03 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>> 
>> 
>> 
>>> On Sep 14, 2018, at 7:57 PM, Patrick Venture <venture@google.com> wrote:
>>> 
>>> Brad;
>>> 
>>> Please create: google-ipmi-sys -- this is to hold OEM IPMI commands we
>>> want to share with the community and vendors, but dont' expect to be
>>> picked up by OpenBMC at large, similar to intel-ipmi-oem.

google-ipmi-sys created.

>> 
>> All the existing OEM IPMI repositories end with -ipmi-oem.  Does that not
>> make sense here?
> 
> So phosphor-ipmi-blobs and phosphor-ipmi-flash are both ipmi-oem
> libraries.  As well as phosphor-ipmi-ethstats.  My thinking was having
> -ipmi- in the name was conveying sufficient information related to
> this.

ok.

Re: New repository Request

[Patrick Venture]

On Mon, Sep 17, 2018 at 10:54 AM Brad Bishop
<bradleyb@fuzziesquirrel.com> wrote:
>
>
>
> > On Sep 17, 2018, at 1:20 PM, Patrick Venture <venture@google.com> wrote:
> >
> > On Mon, Sep 17, 2018 at 7:03 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
> >>
> >>
> >>
> >>> On Sep 14, 2018, at 7:57 PM, Patrick Venture <venture@google.com> wrote:
> >>>
> >>> Brad;
> >>>
> >>> Please create: google-ipmi-sys -- this is to hold OEM IPMI commands we
> >>> want to share with the community and vendors, but dont' expect to be
> >>> picked up by OpenBMC at large, similar to intel-ipmi-oem.
>
> google-ipmi-sys created.

Thank you.

>
> >>
> >> All the existing OEM IPMI repositories end with -ipmi-oem.  Does that not
> >> make sense here?
> >
> > So phosphor-ipmi-blobs and phosphor-ipmi-flash are both ipmi-oem
> > libraries.  As well as phosphor-ipmi-ethstats.  My thinking was having
> > -ipmi- in the name was conveying sufficient information related to
> > this.
>
> ok.

I'm all for consistency in this, I just assumed -ipmi- was sufficient.

Re: New Repository Request

[Patrick Venture]

On Tue, Sep 18, 2018 at 3:37 PM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
> > On Sep 18, 2018, at 11:47 AM, Patrick Venture <venture@google.com> wrote:
> >
> >> On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
> >>
> >> It might be good to have a conversation around how we handle the OpenBMC OEN
> >> though.  Putting things there would seem to have lasting impact for everyone
> >> using OpenBMC and we don’t have any process in place for that.
> >
> > That's correct.  So, right now, the extra handlers aren't enabled to
> > be included in the image by default.
>
> I’m more concerned with the number the end user types in when they run ipmitool.
>
> > Someone would need to select them, which I like.  As that's an opt-in behavior.
>
> I’m not understanding the relationship between opt-in and the OEN number.  In my
> mind there isn’t one.  Isn’t the question instead: for a given OEM extension, is
> the OEN number OpenBMCs or foo-corps (irrespective of whether or not a system
> integrator opts-in or opts-out of including a specific extension in their image).

So the OEN just existing in the source doesn't impact anything.  It
only allows some piece of code to use that number.  And any handlers
that register in that space only exist on a platform if the platform
owner selects them to.  If a functionality isn't there, the ipmitool
users just get an unsupported style error indicative of any command
not recognized -- which is what happens now with the commands that
aren't implemented in the core.

I think the general goal with companies exposing their IPMI special
handlers is to share compliance with each other to some extent, which
is less about the end user and more about infrastructure layers.  I
don't imagine many people playing around with ipmi will care or build
images that enable these extra commands, but companies may.

I'm not sure if that was your concern.

>
> > And if there’s interplay between the things, they can explicitly indicate that in
> > bitbake and in a README.
> >
> > Consider, that each company may want to share their handlers - which I
> > think is great.  It enables vendors, if nothing else, and encourages
> > them to switch to OpenBMC to sell hardware to IBM, Google, etc.  I
> > also prefer the opt-in model for features, which this fits (repeated
> > point).
> >
> > If we share them openly and register the numbers in
> > phosphor-host-ipmid, we can better enable a vendor or someone to say,
> > I want to support _all_ the environments, and just flip all the
> > switches.  To this end, I'm considering re-submitting the oemgoog
> > header to phosphor-host-ipmid, but by flagging its inclusion via a
> > build-time flag.  So, one could say, build a clean phosphor-host-ipmid
> > by building the default, but if they --enable-google or --enable-intel
>
> I feel like there has to be a way to do the same thing without the need for
> —-enable-xyzcorp switches.  I wouldn’t want to maintain that.

Yeah, I went down that road a bit and it doesn't stay pretty long.
But really it's unnecessary to gate whether a header file exists when
that header file only provides a list of numbers.

Re: New Repository Request

[Brad Bishop]

> On Sep 18, 2018, at 11:47 AM, Patrick Venture <venture@google.com> wrote:
> 
>> On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>> 
>> It might be good to have a conversation around how we handle the OpenBMC OEN
>> though.  Putting things there would seem to have lasting impact for everyone
>> using OpenBMC and we don’t have any process in place for that.
> 
> That's correct.  So, right now, the extra handlers aren't enabled to
> be included in the image by default.  

I’m more concerned with the number the end user types in when they run ipmitool.

> Someone would need to select them, which I like.  As that's an opt-in behavior.

I’m not understanding the relationship between opt-in and the OEN number.  In my
mind there isn’t one.  Isn’t the question instead: for a given OEM extension, is
the OEN number OpenBMCs or foo-corps (irrespective of whether or not a system
integrator opts-in or opts-out of including a specific extension in their image).

> And if there’s interplay between the things, they can explicitly indicate that in
> bitbake and in a README.
> 
> Consider, that each company may want to share their handlers - which I
> think is great.  It enables vendors, if nothing else, and encourages
> them to switch to OpenBMC to sell hardware to IBM, Google, etc.  I
> also prefer the opt-in model for features, which this fits (repeated
> point).
> 
> If we share them openly and register the numbers in
> phosphor-host-ipmid, we can better enable a vendor or someone to say,
> I want to support _all_ the environments, and just flip all the
> switches.  To this end, I'm considering re-submitting the oemgoog
> header to phosphor-host-ipmid, but by flagging its inclusion via a
> build-time flag.  So, one could say, build a clean phosphor-host-ipmid
> by building the default, but if they --enable-google or --enable-intel

I feel like there has to be a way to do the same thing without the need for
—-enable-xyzcorp switches.  I wouldn’t want to maintain that.

Re: New Repository Request

[Patrick Venture]

On Tue, Sep 18, 2018 at 3:21 PM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
>
>
> > On Sep 18, 2018, at 11:47 AM, Patrick Venture <venture@google.com> wrote:
> >
> > On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
> >>
> >>
> >>> On Sep 13, 2018, at 1:55 PM, Patrick Venture <venture@google.com> wrote:
> >>>
> >>> Brad,
> >>>
> >>> I'd like to set up a new repository in openbmc to store a google oem
> >>> ipmi library I'd like to share with everybody.  It allows grabbing
> >>> ethernet device statistics over IPMI.
> >>
> >> As far as where the code is hosted I’m good one way or the other.
> >> Will wait a couple days for objections and create openbmc/phosphor-ipmi-ethstats.
> >
> > Please go ahead and create openbmc/phosphor-ipmi-ethstats

Thanks!

>
> done!

Re: New Repository Request

[Brad Bishop]

> On Sep 18, 2018, at 11:47 AM, Patrick Venture <venture@google.com> wrote:
> 
> On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>> 
>> 
>>> On Sep 13, 2018, at 1:55 PM, Patrick Venture <venture@google.com> wrote:
>>> 
>>> Brad,
>>> 
>>> I'd like to set up a new repository in openbmc to store a google oem
>>> ipmi library I'd like to share with everybody.  It allows grabbing
>>> ethernet device statistics over IPMI.
>> 
>> As far as where the code is hosted I’m good one way or the other.
>> Will wait a couple days for objections and create openbmc/phosphor-ipmi-ethstats.
> 
> Please go ahead and create openbmc/phosphor-ipmi-ethstats

done!

Re: New Repository Request

[Patrick Venture]

On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
>
> > On Sep 13, 2018, at 1:55 PM, Patrick Venture <venture@google.com> wrote:
> >
> > Brad,
> >
> > I'd like to set up a new repository in openbmc to store a google oem
> > ipmi library I'd like to share with everybody.  It allows grabbing
> > ethernet device statistics over IPMI.
> >
> > I have no problem registering it under the OpenBMC OEN (and the google
> > one) since OEM registration supports that -- then it could be
> > phosphor-ipmi-ethstats.
> >
> > I really would like to share the code -- but I would be ok with it
> > being in a google-specific repository, such as google-ipmi-ethstats --
> > If so, I'll put the recipe in meta-google.
> >
> > I know we've talked about this before, and it really feels like six in
> > one hand on this —
>
> As far as where the code is hosted I’m good one way or the other.
> Will wait a couple days for objections and create openbmc/phosphor-ipmi-ethstats.

Please go ahead and create openbmc/phosphor-ipmi-ethstats unless you'd
rather create openbmc/google-ipmi-ethstats.  I'm ok with doing the
extra bit of wiring it up to OpenBMC, which would really be the
difference.  But given your concern below -- I'm willing to own it
under google until the implications are worked out.

>
> It might be good to have a conversation around how we handle the OpenBMC OEN
> though.  Putting things there would seem to have lasting impact for everyone
> using OpenBMC and we don’t have any process in place for that.

That's correct.  So, right now, the extra handlers aren't enabled to
be included in the image by default.  Someone would need to select
them, which I like.  As that's an opt-in behavior.  And if there's
interplay between the things, they can explicitly indicate that in
bitbake and in a README.

Consider, that each company may want to share their handlers - which I
think is great.  It enables vendors, if nothing else, and encourages
them to switch to OpenBMC to sell hardware to IBM, Google, etc.  I
also prefer the opt-in model for features, which this fits (repeated
point).

If we share them openly and register the numbers in
phosphor-host-ipmid, we can better enable a vendor or someone to say,
I want to support _all_ the environments, and just flip all the
switches.  To this end, I'm considering re-submitting the oemgoog
header to phosphor-host-ipmid, but by flagging its inclusion via a
build-time flag.  So, one could say, build a clean phosphor-host-ipmid
by building the default, but if they --enable-google or --enable-intel
maybe they get the extra headers included under something like
host-ipmid/oem/oemgoogle.hpp (need to send patch to maintainers for
review sometime today).

>
> >
> > Thanks,
> > Patrick

Re: New Repository Request

[Brad Bishop]

> On Sep 13, 2018, at 1:55 PM, Patrick Venture <venture@google.com> wrote:
> 
> Brad,
> 
> I'd like to set up a new repository in openbmc to store a google oem
> ipmi library I'd like to share with everybody.  It allows grabbing
> ethernet device statistics over IPMI.
> 
> I have no problem registering it under the OpenBMC OEN (and the google
> one) since OEM registration supports that -- then it could be
> phosphor-ipmi-ethstats.
> 
> I really would like to share the code -- but I would be ok with it
> being in a google-specific repository, such as google-ipmi-ethstats --
> If so, I'll put the recipe in meta-google.
> 
> I know we've talked about this before, and it really feels like six in
> one hand on this —

As far as where the code is hosted I’m good one way or the other.
Will wait a couple days for objections and create openbmc/phosphor-ipmi-ethstats.

It might be good to have a conversation around how we handle the OpenBMC OEN
though.  Putting things there would seem to have lasting impact for everyone
using OpenBMC and we don’t have any process in place for that.

> 
> Thanks,
> Patrick

New Repository Request

[Patrick Venture]

Brad,

I'd like to set up a new repository in openbmc to store a google oem
ipmi library I'd like to share with everybody.  It allows grabbing
ethernet device statistics over IPMI.

I have no problem registering it under the OpenBMC OEN (and the google
one) since OEM registration supports that -- then it could be
phosphor-ipmi-ethstats.

I really would like to share the code -- but I would be ok with it
being in a google-specific repository, such as google-ipmi-ethstats --
 If so, I'll put the recipe in meta-google.

I know we've talked about this before, and it really feels like six in
one hand on this --

Thanks,
Patrick