This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1463896 - the configuration script should put warning to /etc/sysconfig/virt-who that users shouldn't modify it manually
the configuration script should put warning to /etc/sysconfig/virt-who that u...
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Virt-who Configure Plugin (Show other bugs)
Unspecified Unspecified
unspecified Severity medium (vote)
: GA
: --
Assigned To: Marek Hulan
Evgeni Golov
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2017-06-21 23:50 EDT by Eko
Modified: 2017-08-30 05:54 EDT (History)
14 users (show)

See Also:
Fixed In Version: foreman_virt_who_configure-0.1.5
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 20296 None None None 2017-07-13 07:02 EDT

  None (edit)
Description Eko 2017-06-21 23:50:17 EDT
When using the virt-who configuration plugin to create a script, but if we run it on the target host, it will delete other options /etc/sysconfig/virt-who, only keep the below options:

Expected results:
Other options are still necessary to keep
Comment 1 Marek Hulan 2017-06-22 04:47:58 EDT
Thanks for the report, What options are necessary and why? It seems the only uncommented value after default installation is "VIRTWHO_DEBUG=0". Maybe the file should contain some comment about that it was generated by the configuration plugin.
Comment 2 Eko 2017-06-22 05:15:10 EDT
I'm afraid if the customers want to set the options by self, such as running hypervisor mode or running for satellite5 by /etc/sysconfig/virt-who, they don't know which options are supported any more. 


# Options for Satellite 5 backend
Comment 3 Marek Hulan 2017-06-22 06:32:40 EDT
I don't think people would try to combine manual and plugin configuration. Would the warning comment on top of the file, that this file is managed by the virt-who-configure plugin, make it clearer?

If customers wants to add new esx hypervisor, they should use the plugin that creates config file in /etc/virt-who.d for it.

If users manually modify configuration that was created by the plugin, it kind of voids the warranty that the configuration is correct.
Comment 4 Eko 2017-06-22 22:52:06 EDT
Hi Chris,

What's your opinion?

is it possible to keep only global options in /etc/sysconfig/virt-who? thus, the hypervisor modes only can be run by CLI or /etc/virt-who.d/xxx.conf
Comment 5 Marek Hulan 2017-06-23 02:38:48 EDT
From my basic knowledge, there's no way to specify interval or debug option in virt-who.d config file. I'd be happy to avoid touching /etc/sysconfig/virt-who if that's possible.
Comment 6 Chris Snyder 2017-07-11 13:19:36 EDT
There are three ways to set the interval:

setting VIRTWHO_INTERVAL to an int in /etc/sysconfig (as is already being done)


setting the '-i' or '--interval' option when running virt-who via the CLI.


setting 'interval' in the '[global]' section of /etc/virt-who.conf to an int.

They are equivalent in function.

We'll have to ask Rich Jerrido but I am under the impression that enough customers configure virt-who using the other values in /etc/sysconfig/virt-who that we should still support them.

Rich thoughts on the above?


I would also ask, what happens when one runs two scripts generated by the virt-who satellite plugin on the same system? I would presume that the global values set in the script run last on the system would be the ones that remain.

Comment 7 Rich Jerrido 2017-07-11 19:37:27 EDT
In a Satellite 6.x use-case with the configuration script, I would treat the configurations that are in /etc/sysconfig/virt-who AND /etc/virt-who.d/* as being 'owned' by the configuration script.

Outside of the options listed in comment #0 (shown below), I can't think of any needed. (most of the /etc/sysconfig/virt-who options can be also/alternatively be set in /etc/virt-who.d/).


Basically, I'd be OK with us placing a notice in the config file similar to 

### This configuration managed via the virt-who plugin
### manual edits will be deleted. 

I would like to take the stance (and I think we should document it as such) that virt-who configurations that are managed via the virt-who plugin, should SOLELY be managed by the virt-who plugin. 

This is similar to any other configuration file managed by the installer/application.
Comment 8 Marek Hulan 2017-07-13 07:01:02 EDT
Thanks Chris. So until there's a way to have different interval per worker, I think changing /etc/sysconfig/virt-who is the best option at the moment. I agree with what Rich described, so I'll add the comment in to the top of the file.

You're right about two configurations overriding the same value. Since there's no way to set different interval per hypervisor, we'll have to live with it for now. Hopefully people will use recommended value and keep the default interval. I don't see any RFE for virt-who to enable different intervals per hypervisor, should I open one against virt-who?
Comment 9 Marek Hulan 2017-07-13 07:02:44 EDT
Created redmine issue from this bug
Comment 10 Marek Hulan 2017-08-14 16:04:53 EDT
Bryan, I'm lowering the priority. As per comment 7, we should only provide a comment into the config file so people are warned if they are modifying the config file manually. Please reset if you think it's still high priority.
Comment 12 Evgeni Golov 2017-08-30 05:54:12 EDT

Version tested:
Satellite 6.3 Snap 13

* created a new virt-who config in the WebUI
* hammer virt-who-config deploy --id 1
* head -n2 /etc/virt-who.d/virt-who-config-1.conf 
### This configuration file is managed via the virt-who configure plugin
### manual edits will be deleted.
* # head -n2 /etc/sysconfig/virt-who 
### This configuration file is managed via the virt-who configure plugin
### manual edits will be deleted.

Note You need to log in before you can comment on or make changes to this bug.