CLI Tools

[Wilfred Smith]

All,

I’m not sure what OpenBMC’s or Facebook’s official stance on CLI is, so consider this comment to be a “shot from the hip” of someone who means well.

It seems to me that at least three buzzwords require invocation: consistency, discoverability and automation. Obviously any developer who cares enough to plumb the bowels of a vendor’s D-bus implementation can write his own utilities and has many means of accomplishing his objectives. But those areas are critical for the devop who just needs to get a task done and cares little about a particular vendor’s implementation.

1. It would be good to agree on a set of common, simplified commands for key operations that do not impose a steep learning curve. (Committing “disable auto-reboot” to memory is reasonable; committing “busctl …long hierarchical path…15 parameters” is not)
2. It would be good to have a common means of discovering the available tool(s), their most common usages and adaptations. …possibly as simple as having a good base “man” page that vendors can adapt. (it’s 3 AM, there’s a power grid failure and you need to recover from a cluster fault without doing a Google search…can you figure it out, even if you’ve never done it before?)
3. To enable automation in production, the commands should be scriptable and the means of catching and handling errors should be well-defined. (Thanks for the exit code 1, I know “something” is wrong…let me determine “You can’t reconfigure the FCoE connection because the NIC is offline” and allow a script to detect that, enable the NIC and carry on).
4. Further, I think obmcutil should be extensible in a manner compatible with Bitbake layers. This may avert the proliferation of vendor-specific, incompatible, functionally differing tools. It should be a framework that makes it easier to develop and extend compliant tools than to roll “Andy-dbg-nvme-cfg”

Wilfred 



> On Jul 24, 2019, at 7:58 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> 
> 
> 
> On Thu, 25 Jul 2019, at 11:58, Brad Bishop wrote:
>> On Thu, Jul 25, 2019 at 11:06:13AM +0930, Andrew Jeffery wrote:
>>> Hi Wilfred,
>>> 
>>> On Wed, 24 Jul 2019, at 14:04, Wilfred Smith wrote:
>>>> There was a discussion a while back (2 years ago? In
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2016-2DNovember_005307.html&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=-ektT-tD9zf2rfUisE63RqiDagGyhGey2hbEGa-47kc&m=z0EEIpo6k4yQxVtT14vhkqxHDpyyymwj4U8p5gpO140&s=Kr2nAn2xlXfEc0WFaemmDme66nyV2FHI6kg9WRrmdsc&e= )
>>>> where the OP (Patrick Williams) expressed concern over the
>>>> proliferation of command line tools. Patrick’s interest involved how to
>>>> integrate iotools. Others chimed in questioning whether it’s better to
>>>> provide compact commands for common needs or encourage exploration by
>>>> requiring longhand. Patrick inquired about the target audience for the
>>>> tools.
>>> 
>>> I'm all for helpers for common tasks. If we can integrate them into obmcutil
>>> that would be ideal. The alternative is that we require people write things like:
>>> 
>>> # busctl set-property `mapper get-service /xyz/openbmc_project/control/host0/auto_reboot` /xyz/openbmc_project/control/host0/auto_reboot xyz.openbmc_project.Control.Boot.RebootPolicy AutoReboot b false
>>> 
>>> to disable auto-reboot or
>>> 
>>> # busctl set-property xyz.openbmc_project.Network /xyz/openbmc_project/network/eth0 xyz.openbmc_project.Network.EthernetInterface DHCPEnabled b 1
>>> 
>>> to switch DHCP on. Quite frankly that's a ridiculous requirement to force on
>>> everyone.
>> 
>> Years ago when Patrick wrote the referenced note, the belief was that 
>> the OpenBMC DBus API would be stable.  But that thinking has long since 
>> been rejected - the OpenBMC DBus is not stable and as such it probably 
>> doesn't make sense to be sharing it (via busctl commands) with our 
>> users?
> 
> Yeah, lifting an obmcutil interface to represent something users want to
> achieve (`obmcutil dhcp enable`) rather than exposing implementation
> details would be a win.
> 
>> 
>>> 
>>> Having said that some of these already have shortcuts, such as
>>> 
>>> # systemctl stop host-failure-reboots at 0
>> 
>> It might already be too late, but we probably should not have presented 
>> systemctl commands as stable interfaces for our users either, for the 
>> same reasons as I've mentioned above.
> 
> Right.
> 
> Andrew