[ClusterLabs] Antw: Re: Antw: Coming in Pacemaker 2.0.3: crm_mon output changes

[Ken Gaillot]

On Wed, 2019-10-16 at 08:08 +0200, Ulrich Windl wrote:
<snip>
> > > > Why not replace "--weg-cgi" with "--output-format=cgi"?
> > 
> > CGI output is identical to HTML, with just a header change, so it
> > was
> > logically more of an option to the HTML implementation rather than
> > a
> > separate one.
> > 
> > With the new approach, each format type may define any additional
> > options to modify its behavior, and all tools automatically inherit
> > those options. These will be grouped together in the help/man page.
> > For
> > example, the HTML option help is:
> > 
> > Output Options (html):
> >   --output-cgi                      Add text needed to use output
> > in a CGI 
> > program
> >   --output-meta-refresh=SECONDS     How often to refresh
> 
> God bless the long options, but considering that the only thing that
> is
> refreshed in crm_mon's output is... well the output,,, why not just
> have
> --refresh or --refresh-interval.

One of the goals is to have options that are consistent across all
tools. We came up with the "--output-" prefix to make it easy to avoid
conflicts with existing/future tool options.

However, I think you're right that it's confusing. I'm thinking that
instead, we can reserve each of the format types as an option prefix.
For example, for html it would become:

Output Options (html):
  --html-cgi                 Add text needed to use output in a CGI program
  --html-stylesheet=URI      Link to an external CSS stylesheet
  --html-title=TITLE         Page title

which I think is a little shorter and more intuitive. There are a few
existing --xml-* options we'd have to work around but I don't think
that's a problem.

Does that make more sense?

BTW we decided to get rid of --output-meta-refresh altogether, and just
continue using the existing --interval option for that purpose.

> Also it wouldn't be too har
> d (if there's any demand) to allow suffixes like
> 's' for seconds, 'm' for minutes, and most likely more do not make
> sense for a
> refresh interval.

Actually it already does, it's just not in the help description. We'll
update the help.

<snip>
> > > > When called with ‑‑as‑xml, crm_mon's XML output will be
> > > > identical
> > > > to
> > > > previous versions. When called with the new ‑‑output‑as=xml
> > > > option,
> > > > it
> > > > will be slightly different: the outmost element will be a
> > > > <pacemaker‑
> > > > result> element, which will be consistent across all tools. The
> > > > old
> > > > XML
> > > 
> > > Why not as simple "status" element? "-result" doesn't really add
> > > anything
> > > useful.
> > 
> > We wanted the design to allow for future flexibility in how users
> > ask
> > pacemaker to do something. The XML output would be the same whether
> > the
> > request came from a command-line tool, GUI, C API client
> > application,
> > REST API client, or any other future interface. The idea is that
> > <pacemaker-result> might be a response to a <pacemaker-request>.
> 
> But most likely any response will be a kind of result, so why have
> "result"
> explicitly? Also as it's all about pacemaker, why have "pacemaker" in
> it?
> (Remember how easy it was to get rid of "heartbeat"? ;-))
> So my argument for "status" simply is that the data describes the
> status.

The idea is that if the output is saved to a file, someone looking at
that file later could easily figure out where it came from, even
without any other context.

> > All of the format options start with "--output-" so we can reserve
> > those option names across all tools.
> 
> Do you actually have a big matrix of all options available across the
> tools?
> I'd like to see!

Me too. :) Not yet, we just grep for a new option name we're thinking
of using. That's why we went with the "--output-" prefix, it was easy
to make them unique. :)
-- 
Ken Gaillot <kgaillot at redhat.com>