CLI Tools

Andrew Geissler geissonator at
Fri Jul 26 06:33:01 AEST 2019

On Thu, Jul 25, 2019 at 2:20 PM Wilfred Smith <wilfredsmith at> wrote:
> 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”

I definitely agree on all fronts. I've gotten a lot of complaints as we've
changed D-bus API's and target names over the years. We created openbmcutil as
our standard for out of band access[1] (similar complaints with our custom REST
api's). Moving to Redfish and our ability to use off the shelf tools like
Redfishtool should slowly deprecate most of openbmcutil.

As noted above, for internal, we've got obmcutil[2]. We recently moved obmcutil
from a python based app to bash so that we could make python optional in our
phosphor layer.

I'd definitely be interested in ways to add bitbake-layer based options to this
tool, but hopefully without having to add python back.

The biggest issue I've seen with tools is that it becomes a new interface which
must continue to always be supported. It definitely comes with a cost so we
always want to be conscious of what we add to it.

High on my list is the ability to disable autoreboots and/or the host watchdog.
Listing, clearing, and displaying phosphor-logging events would be nice.


> Wilfred
> > On Jul 24, 2019, at 7:58 PM, Andrew Jeffery <andrew at> 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
> >>>> )
> >>>> 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

More information about the openbmc mailing list