Description of problem:
If I modify a config file for virt-who under /etc/virt-who.d/ with a different extension then .conf it will still be considered as a config file.
[root@provisioning virt-who.d]# ll
-rw-r--r--. 1 root root 290 Jul 20 12:04 rhevm.conf
-rw-r--r--. 1 root root 306 Aug 22 15:40 satotest2.conf.bkp
-rw-r--r--. 1 root root 305 Feb 29 10:37 satotest.conf
-rw-r--r--. 1 root root 1212 May 24 12:19 template.conf
For example .bkp extension is still being picked up by virt-who:
# egrep -i "\[" *
If I restart the virt-who service:
# egrep -i "using configuration" /var/log/rhsm/rhsm.log
2016-08-22 15:41:08,247 [INFO] @virtwho.py:697 - Using configuration "satotest" ("libvirt" mode)
2016-08-22 15:41:08,247 [INFO] @virtwho.py:697 - Using configuration "rhevm" ("rhevm" mode)
2016-08-22 15:41:08,247 [INFO] @virtwho.py:697 - Using configuration "satotest3" ("libvirt" mode)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Change extension of config file for virt-who under /etc/virt-who.d/
Old config is still being picked up by virt-who
Restrict the config file to only .conf or we need to provide better info to our customers as many people prefer to change file to .bkp or with a date then removing it immediately.
Although I agree that virt-who shouldn't pickup all files in /etc/virt-who.d, I don't think we can change that. Our customer might have config files without extension (or with extension different from .conf) in /etc/virt-who.d and if we started to ignore them, it would break for them.
virt-who in RHEL-7.3 will at least ignore hidden files, so at least there will be a workaround for this. Or deleting (commenting out) the "[section]" line will make virt-who ignore the config file (but it creates a warning in the log).
I've added a note about the behavior to the man page (upstream only for now):
This RFE has been implemented upstream in the PR added as an external tracker to this bug. As this has been merged upstream and will be included in the first build for rhel 7.4 I'm moving this bug to the MODIFIED state.
Verified the bug with RHEL-7.4-20170324.n.0, virt-who will ignore the "xen" and "esx.conf.bkp" configuration files, just run the "esx.conf" and "xen.conf" file.
There is some concern in CEE now for this BZ's changes that were recognized from testing in customer environments with a recent build of virt-who:
The message below depicts what it currently looks like when a config is not found:
2017-05-08 13:26:25,548 [INFO] @main.py:164 - No configurations found, using libvirt as backend
I know that the config bits are being reworked, but in the immediate case of this BZ being pushed out to customers via 7.4, our worry is that there are a rather large number of customers currently using the non-standard naming scheme for their configs inside the drop directory. (For example, 'one', 'two', etc..)
Customers that are using configurations that do not contain '.conf' are not getting any hints that this is suddenly a constraint since it has not been before now.
We would like to change this slightly to include a hint that they may have incorrect naming.
Something along the lines of:
2017-05-08 13:26:25,548 [INFO] @main.py:164 - No configurations found (are there any '.conf' files inside /etc/virt-who.d?), using libvirt as backend
You can make the wording however you see fit, as long as we try to key off customers into the change without necessarily needing to open a case for just simply updating virt-who and now it will not load my config files.
(Don't get me wrong, we /want/ the naming constraint. This makes it simply to rename configurations we don't want to currently use and prevent them from being loaded anyway without having to move them from the directory.)
It would be best to attempt to eliminate case-load via this INFO message rather than having to throw a KCS at each customer this occurs for.
Comment 6 makes eminent sense to me.
I will modify the message as requested.
Attaching a PR with the requested log changes. In addition, the virt-who-config man pages have been updated to indicate the requirement of config files ending in '.conf'.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.