[ClusterLabs] Antw: Re: Antw: Coming in Pacemaker 2.0.3: crm_mon output changes
kgaillot at redhat.com
Mon Oct 21 14:28:53 EDT 2019
On Wed, 2019-10-16 at 08:08 +0200, Ulrich Windl wrote:
> > > > 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
> refreshed in crm_mon's output is... well the output,,, why not just
> --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.
> > > > 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
> explicitly? Also as it's all about pacemaker, why have "pacemaker" in
> (Remember how easy it was to get rid of "heartbeat"? ;-))
> So my argument for "status" simply is that the data describes the
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
> 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>
More information about the Users