CLI Tools

[Andrew Jeffery]

On Fri, 26 Jul 2019, at 06:03, Andrew Geissler wrote:
> On Thu, Jul 25, 2019 at 2:20 PM Wilfred Smith <wilfredsmith at fb.com> 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.

Right. This is where mapping the supported actions to high-level uses-cases is
important - we want to make sure we don't bake implementation details into the
interface. To a degree some of the structure imposed by IPMI (via ipmitool) /
Redfish (via redfishtool) / phosphor-dbus-interfaces can be used to inform what
these high level operations might be.

The fact that obmcutil is a shell-script as opposed to python shouldn't have too
much of an impact. 

Andrew