Policy on Tools Posting

[Vijay Khemka]

On 8/16/19, 12:58 PM, "openbmc on behalf of Andrew Geissler" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of geissonator at gmail.com> wrote:

    On Thu, Aug 15, 2019 at 6:03 PM Joseph Reynolds <jrey at linux.ibm.com> wrote:
    >
    >
    > On 8/15/19 4:57 PM, Wilfred Smith wrote:
    > > My manager (Sai) is asking whether there is precedence for having utilities posted outside the OpenBMC repository. Do we want 100 OpenBMC tools repositories, each managed differently or 1 harmonized repository?
    > >
    > > Separately, is there any effort to create a “common core” for OpenBMC such that an effort akin to POSIX or the Single UNIX Specification isn’t needed ten years from now? Without standard API (or at least abstracted tools) for things like where FRU information is located or sending IPMB commands, isn’t the market for innovative software stifled (Android software market vs iOS, or even Linux vs Windows)?
    >
    > My view is to focus on enhancing the Redfish functions so that users of
    > OpenBMC systems can do everything they need to without having use Secure
    > Shell (ssh) or any of the command line utilities ssh can access (such as
    > systemctl, busctl, or obmctool).  See some publicly-readable IBM
    > discussion on this topic here: https://github.com/ibm-openbmc/dev/issues/612
    
    Once a system has shipped to a customer, ensuring 99% of what they need
    to use that server is available via Redfish definitely makes sense to me.
    
    > Meanwhile, when us developers need to access the BMC via ssh, we are
    > happy to use the existing command line utilities and don't see the need
    > for any more.
    
    Hmm, I don't think I agree with this. I think obmcutil has provided a
    lot of useful
    abstraction for developers and users of OpenBMC (like our lab team).
    No one really wants to remember some of the long cumbersome commands
    done by obmcutil, nor do they want to deal with situations where we change
    the underlying D-bus API in a certain version of firmware. obmcutil provides a
    nice abstraction to that and I could see tools that provide abstractions for
    looking at error logs or listing system inventory could also be useful. I don't
    think these tools should ever be things people purchasing OpenBMC based
    products count on using (but they could still be there if they wanted).

I agree with Andrew here. There are many instances where simple commandline 
utility helps in debugging and quickly testing rather than searching through all long 
commands.

I would prefer to have these ipmb, fru and sensor utils to be hosted in the repo 
Where obmcutil are. I couldn't find repo for obmcutil.
    
    >
    > I would prefer to see our energy focused on enhancements to Redfish and
    > on utilities which use the Redfish APIs (akin to redfishtool).
    >
    > - Joseph
    >
    > >
    > > Wilfred
    > >
    > >> On Aug 15, 2019, at 12:41 PM, openbmc-request at lists.ozlabs.org wrote:
    > >>
    > >> Send openbmc mailing list submissions to
    > >>      openbmc at lists.ozlabs.org
    > >>
    > >> To subscribe or unsubscribe via the World Wide Web, visit
    > >>      https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_listinfo_openbmc&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=-ektT-tD9zf2rfUisE63RqiDagGyhGey2hbEGa-47kc&m=CsXIqDLC_9ZYrVSwNllcHo7GjqAG9mj2S6NymPQTblk&s=_RrYmmMf-6XU6r5LsXsWLj8G0K_qaWyo6K2yDU5JGu8&e=
    > >> or, via email, send a message with subject or body 'help' to
    > >>      openbmc-request at lists.ozlabs.org
    > >>
    > >> You can reach the person managing the list at
    > >>      openbmc-owner at lists.ozlabs.org
    > >>
    > >> When replying, please edit your Subject line so it is more specific
    > >> than "Re: Contents of openbmc digest..."
    > >>
    > >>
    > >> Today's Topics:
    > >>
    > >>    1. Re: Policy on Tools Posting (Vijay Khemka)
    > >>    2. [PATCH dev-5.2] fsi: scom: Don't abort operations for minor
    > >>       errors (Eddie James)
    > >>    3. Re: [PATCH] net/ncsi: Ensure 32-bit boundary for data cksum
    > >>       (David Miller)
    > >>    4. Re: [PATCH v4 2/2] hwmon: pmbus: Add Inspur Power System
    > >>       power supply driver (Guenter Roeck)
    > >>
    > >>
    > >> ----------------------------------------------------------------------
    > >>
    > >> Message: 1
    > >> Date: Thu, 15 Aug 2019 19:07:26 +0000
    > >> From: Vijay Khemka <vijaykhemka at fb.com>
    > >> To: Andrew Geissler <geissonator at gmail.com>, Wilfred Smith
    > >>      <wilfredsmith at fb.com>
    > >> Cc: "openbmc at lists.ozlabs.org" <openbmc at lists.ozlabs.org>
    > >> Subject: Re: Policy on Tools Posting
    > >> Message-ID: <68929B76-8826-4DAD-A29E-DF7A119D00C5 at fb.com>
    > >> Content-Type: text/plain; charset="utf-8"
    > >>
    > >>
    > >>
    > >> ?On 8/15/19, 5:59 AM, "openbmc on behalf of Andrew Geissler" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of geissonator at gmail.com> wrote:
    > >>
    > >>     On Mon, Aug 12, 2019 at 7:58 PM Wilfred Smith <wilfredsmith at fb.com> wrote:
    > >>>
    > >>> 1. Are there guidelines/procedures specific to submitting command line tools and utilities? I have heard that there may be a repository and/or path dedicated to CLI tools.
    > >>     The community has definitely tended to limit wrapper tools within
    > >>     OpenBMC. We had a discussion a while back that we're open to some but
    > >>     the API's to them really need to be thought out and reviewed because
    > >>     command line tools become customer API's (i.e. people start writing
    > >>     scripts on top of these tools that then become key to the
    > >>     manufacturing process or some other critical area).
    > >>
    > >>     Anything that goes into OpenBMC needs to support OpenBMC interfaces.
    > >>     For example, I'm not familiar with fruid-util's D-bus service
    > >>     xyz.openbmc_project.FruDevice. A "busctl tree
    > >>     xyz.openbmc_project.Inventory.Manager | cat" shows the inventory items
    > >>     on OpenBMC.
    > >>
    > >>     One issue we have within OpenBMC is there may be different
    > >>     implementations of the D-bus API's for a given area. For example,
    > >>     Inventory has different implementations so I'm not sure which repo
    > >>     would best fit your tool. That type of issue leads me to wonder if we
    > >>     should put the tools with the interface definitions in
    > >>     openbmc/phosphor-dbus-interfaces? Or maybe a separate phosphor-tools
    > >>     repo would be more logical for these.
    > >> Andrew, I like the idea of having phosphor-tools which can be a placeholder
    > >> for any commandline tools and can grow as per requirement. Currently
    > >> it can start with 3 proposed tools.
    > >>
    > >>     Either way, I think command line tools should each get their own
    > >>     mini-design doc
    > >>     (https://github.com/openbmc/docs/blob/master/designs/design-template.md)
    > >> Wilfred, Can you please create a document as per this design template and submit for review.
    > >>
    > >>     with requirements and interfaces clearly defined for review by the
    > >>     community. If we can find a generic tool that multiple people find
    > >>     useful, we can then find a place to put it. Otherwise, you could host
    > >>     your tools outside of openbmc/ github and just pull them into recipes
    > >>     from within your meta-facebook layer.
    > >>
    > >>> Thanks in advance,
    > >>>
    > >>> Wilfred
    > >
    > ...snip...
    >