Policy on Tools Posting

[Joseph Reynolds]

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

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.

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...