Bug 1369107
| Summary: | RFE config files under /etc/virt-who.d/ are picked up no matter what the extension is | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Kenny Tordeurs <ktordeur> |
| Component: | virt-who | Assignee: | Patrick Creech <pcreech> |
| Status: | CLOSED ERRATA | QA Contact: | Eko <hsun> |
| Severity: | low | Docs Contact: | Jiri Herrmann <jherrman> |
| Priority: | low | ||
| Version: | 7.2 | CC: | ajambhul, cdonnell, csnyder, jherrman, khowell, pcreech, yuefliu |
| Target Milestone: | rc | Keywords: | Documentation, FutureFeature, RFE, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Release Note | |
| Doc Text: |
*virt-who* configuration files are easier to manage
The *virt-who* service now only uses configuration files in the `/etc/virt-who.d/` directory that end with the `.conf` extension. This enables easier management of *virt-who* configuration files, for example for testing or backup purposes.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 19:24:47 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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): https://github.com/virt-who/virt-who/commit/1b12c621b1c560f5dcc11fe3440cedc4911ba3b7 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. - virt-who-0.19-1.el7.noarch - subscription-manager-1.19.4-1.el7.x86_64 - python-rhsm-1.19.2-1.el7.x86_64 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. Thanks. 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. https://access.redhat.com/errata/RHBA-2017:2084 |
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 total 16 -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 "\[" * ~~~ rhevm.conf:[rhevm] satotest2.conf.bkp:[satotest3] satotest.conf:[satotest] ~~~ 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): virt-who-0.14-9.el7_2.1.noarch How reproducible: 100% Steps to Reproduce: 1. Change extension of config file for virt-who under /etc/virt-who.d/ 2. 3. Actual results: Old config is still being picked up by virt-who Expected results: 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. Additional info: