Hi guys,
> > On 22/04/13 11:55, Mark Goodwin wrote:
> > I guess we could modify pmafm so the "replay" command used this scheme.
FWIW, I'm not really sure any pmafm modifications are needed - if the
wrapper tools do (b) correctly and /var/lib/pcp/config/pmafm is added
to appropriately, then (a) is solved with no pmafm changes.
> > e.g. even though pmcollectl creates a pmafm folio, pmafm replay on
> > that folio fails because (a) pmafm doesn't know about pmcollectl
> > (easily fixed), (b) the folio doesn't have the correct comment header
> > (easily fixed), but (c) pmcollectl doesn't grok the standard -a archive
> > option .. it uses -p.
> >
> > Problem (c) is a candidate to be fixed using this new scheme, but I
I'd say "candidate" is the wrong word here - rather, the entire point of
this scheme is to address problem (c).
> > sort of wonder - are we promoting cmd line option inconsistencies
> > by fixing these kinds of problems in this way? If we were to reimplement
Certainly not "promoting" - "dealing with contradictory arguments and
conflicting requirements" is the aim here.
> > the sysstat suite in pcp/py, we'd sort of have no choice but to
> > honour the cmdline options of the original tools.
*nod* ... but ... that is the whole point.
> On 22/04/13 15:31, Ken McDonell wrote:
> We have a command line argument "standard" in PCP. We should stick to
> that for all existing and any new PCP tools we create.
*nod*, that's the idea.
> You can add --fluff support syntax if you wish, but this is (a) extra
> and (b) not mandated ... so I am not sure of the point, independent of
> my religious objections to this style of command line arguments (yes, I
> am a dinosaur, but I don't think --help, rather than -\?, has ever
> helped me solve a usability problem).
Eh? Not sure what that has to do with this commit. Long arguments are
an orthogonal issue, this commit will work with or without them, doesn't
affect this.
> As to things that are re-implementations of existing tools, they should
> *preserve* the syntax of the existing tools, even if the underlying
*nod*, yes, that's the whole point of this.
> implementation is replaced by something using the PCP APIs. The really
> problematic issues come when you want to expose some PCP functionality
> (like replay from archives, or setting a time window, or timezone
> handling, or PCP debug flags, or ...) that the original tool does not
> support and these are not generally solvable, other than case-by-case
I disagree there, they *are* generally solvable, and that is what this
commit is starting to address. I really, really disagree with each and
every wrapper tool going case-by-case and doing its own thing. There
could be many, many of these tools within a year or two - it will be
total anarchy - we should provide some direction. And we should do it
transparently - it looks like all/most of these wrappers will be python
scripts, and I expect the env vars can be handled in the python classes
without wrapper tool intervention.
> analysis that honours the original user interface of the tool and tries
> to shoe-horn the new PCP command line options alongside ... this will
> inevitably involve compromise and command line inconsistency, but c'est
> la vie.
I am asserting that we can do better than just giving up here, that is
what this commit is all about (wierdly, alot of what you are both wanting
seems to me to be what this commit is attempting to provide you with! It
is entirely possible we three are all in violent agreement here).
Shoe-horning PCP options into those that the existing tools use is a poor
approach IMO, and disregards the worst case - where we pick a new cmdline
option to shoe-horn with (in the wrapped tool), and then in a subsequent
"upstream" release of the wrapped tool, that option gets used! Then we'd
be between a rock and a hard place, and forced to break compatibility one
way or the other. We don't need to ever have that problem if we plan
ahead sufficiently early (now).
IMO, this scheme is elegant in that it provides a way to coexist peacefully
and provide an exact drop-in replacement for the upstream tool - being both
100% "upstream" command line compatible (via the sub-command options) and
100% "stock PCP option" compatible (via the pcp-command options).
Giving up is not an option! ;)
cheers.
--
Nathan
|