Some thoughts which I also wrote in the case:

If we would flag these files as configfiles,

- users could modify them as they like, and pmlogconf would
  produce the desired output 
- but we should then probably extend our test matrix for QE:
  a customer who has installed pcp on rhel8.0 could have
  finetuned all of the files 
  /var/lib/pcp/config/pmlogconf/zeroconf/* and we would have
  to test if after a PCP upgrade (which would then not overwrite
  his files) the system behaves sane.  PCP sees quite heavy
  rebases.. maybe we want these files in sync with the PCP version.

In other words, when pcp-zeroconf changes these files between versions,
then a customer who has a customized version would not notice, he would
continue to use his version and the new version.
Just something to consider if this change gets done.

This has actually already been fixed, and is planned for inclusion in 8.5 via rebase BZ 1922040.

In current versions of PCP the pmlogconf files below /var are now symlinks to (config) files below /etc and these files are managed using the regular rpm heuristics dealing with configuration files.

| Also there is no easiest way to recreate the configuration file.

You can run pmlogconf at any time to recreate the pmlogger config file.  You can re-install the pcp RPMs to recreate pmlogconf config files.

| Why is the configuration of the pmlogger not simply intuitive and following the standard of using '.d' directories.

Because noone ever implemented that I guess, and configuring pmlogger is already quite a complex process.

FWIW, the control file (/etc/pcp/pmlogger/control) do allow per-host configuration using a directory-based configuration (control.d).

*** This bug has been marked as a duplicate of bug 1922040 ***

>> Also there is no easiest way to recreate the configuration file.
> You can run pmlogconf at any time to recreate the pmlogger config file.  You can re-install the pcp RPMs to recreate pmlogconf config files.

Sorry, it is not posisible to re-create from scratch the pmlogconf without including the current config.default values. For example if i remove or make a file below /var/lib/pcp/config/pmlogconf/zeroconf empty then a re-run of pmlogconf will still include the old values.


> FWIW, the control file (/etc/pcp/pmlogger/control) do allow per-host configuration using a directory-based configuration (control.d).

Sorry, this again does not guide the user:
- pmlogger/control is a single line per host. The only use case for control.d is to split a single file of local and another for remote. For the rest it still depends on the configuraiton file specified in the '-c' option.
- How do you create the per-host configuration file? There is no simple guidance nor intuitive
- What is the best practice to you monitor an environment consisting of various minor releases and different PCP releases? E.g. how create the most efficient configuration files for remote monitoring for each of the following minor releases where each listed minor release has been 1-200 servers attach?
   - RHEL6.10-ELS
   - RHEL7.6-E4S
   - RHEL7.9
   - RHEL8.2-E4S
   - RHEL8.3
- During the start of the pmlogger processes the configuration file might be re-created or updated unless you set the (pretty good hidden) feature '$PMLOGGER_CHECK_SKIP_LOGCONF=yes'

> This has actually already been fixed, and is planned for inclusion in 8.5 via rebase BZ 1922040.> 
> In current versions of PCP the pmlogconf files below /var are now symlinks to (config) files below /etc and these files are managed using the regular rpm heuristics dealing with configuration files.

Where is this documented? In https://github.com/performancecopilot/pcp/blob/main/CHANGELOG i cannot find anything indicating a change.

pmlogconf is simply a convenience utility for managing auto-generated pmlogger configuration files.  It is not mandatory.

If its behaviour does not provide a pmlogger config file in the form you wish to see, or you dislike some aspect of its implementation, you are free to use different mechanisms for managing these configuration files.  If a pmlogger config file (referenced by -c in a control file) a/ exists and b/ doesn't contain the pmlogconf-version header on the first line, it will not be considered for re-generation by pmlogconf during pmlogger service startup.

Where is this all documented?


Looking in /var/lib/pcp/config/pmlogger/config.default i see:
------
#pmlogconf 2.0
#
# pmlogger(1) config file created and updated by pmlogconf
# Auto-generated by pmlogconf on:  Wed Mar 24 15:10:31 UTC 2021
#
# DO NOT UPDATE THE INITIAL SECTION OF THIS FILE.
# Any changes may be lost the next time pmlogconf is used
# on this file.
#
----------

To me this means i should not touch the file because it is _always_ regenerated and i should not modify it manual or manage with Puppet.

If pmlogconf is a convenience utility then it SHOULD NEVER be called from the pmlogger start process.
I expect that the pmlogger service fails to start if the configuration file (config.default) is missing. In that case it can nicely inform the user to create the config.default file with the pmlogconf convenience utility.

(In reply to Peter Vreman from comment #6)
> Where is this all documented?
> 
> Looking in /var/lib/pcp/config/pmlogger/config.default i see:
> [...]

Peter, please stop setting NEEDINFO from me on this BZ.  I'm not involved
in writing documentation beyond upstream PCP docs, and that is not the topic
of this BZ.  If you'd like to see additional docs, please open a docs BZ.

> To me this means [...]

I've described how PCP works.  If you don't like it, feel free to get involved
with upstream development and make your case there - that is where these sorts
of decisions are made, not in Red Hat bugzilla.  https://pcp.io/community.html

cheers.

I am only trying to provide real-world feedback on a product that RedHat supports and promotes. Every RHEL8.x release notes mention and promise PCP improvements. As an end-user i do not really see these improvements. For me as paying RedHat customer I feel the need to open Cases to describe my the daily challenges on PCP configuration.

The original case I opened is that cannot easily override pcp configuration including pcp-zeroconf. This BZ is created out of it. For me the case is really more than just marking files as %config in RPM. The challenge i have keeps to be being that it is hard to tailor the PCP configuration. And part of the problem is the automatic updating of the config.default file.

Please look at things not only from engineering point of view. I am trying to provide real-world feedback from an user perspective on my daily challenges to configure RedHat. The feedback is there to support RedHat that it can provide a better user-experience for all RedHat customers.

(In reply to Peter Vreman from comment #8)
> [...]
> Please look at things not only from engineering point of view. I am trying
> to provide real-world feedback from an user perspective on my daily
> challenges to configure RedHat. The feedback is there to support RedHat that
> it can provide a better user-experience for all RedHat customers.

I appreciate your feedback, and that you're a RHEL customer - very much.

I reiterate my earlier points (albeit little abruptly, my apologies, it was the end of a long day) though.  The ideal way to collaborate and provide your feedback to all PCP developers (about core PCP functionality and pain points) is not here in Red Hat bugzilla, but in the upstream PCP community channels.

This is where the software originates, and where all technical decisions are made that eventually feed back into the RHEL PCP packages.  Certainly our (relatively small) Red Hat PCP team will do its best to assist you with these BZs, but there are more minds than ours in the wider community who can also advise, help out, and who will also benefit from receiving your feedback.

Thanks Peter!